Blockchain With Daisy Chained Records

ABSTRACT

Permissioned blockchains with off-chain storage establish integrity and no-later-than date-of-existence for documents, leveraging records containing hash values of documents. When a document&#39;s integrity or date is challenged, a new hash value is compared with a record in the blockchain. Proving date-of-existence (via hash value in a publication and/or SMS) for the block containing the record establishes no-later-than date-of-existence for the document. Permissioning monetizes operations, enforcing rules for submission rights and content, thereby precluding problematic material (privacy, obscenity, malicious logic, copyright violations) that threatens long-term viability. Compact records and off-chain storage in a document corral (with quarantine capability) preserve document confidentiality and ease storage burdens for distributed blockchain copies. Using multiple hash values for each document hardens against preimage attacks with quantum computing. Daisy chaining records establishes that relationships existed among documents at registration. Self-addressed blockchain registration (SABRe) permits documents to self-identify their blockchain record address (block ID, index).

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation in part of U.S. patent applicationSer. No. 16/848,759, filed Apr. 14, 2020, titled “Blockchain With DaisyChained Records, Document Corral, Quarantine, Message Timestamping, AndSelf-Addressing”, and claims priority thereto. This application furtherclaims the benefit of U.S. Provisional Patent Application No.62/980,467, filed Feb. 24, 2020, titled “Blockchain With Daisy ChainedRecords, Document Corral, Quarantine, Message Timestamping, AndSelf-Addressing”, the entirety of which is hereby incorporated byreference herein; and also further claims the benefit of U.S.Provisional Patent Application No. 62/841,406, filed May 1, 2019, titled“Blockchain With Daisy Chained Record References”, the entirety of whichis hereby incorporated by reference herein.

BACKGROUND

Blockchain records regarding documents are generally isolated entities.Thus, for off-chain storage, when a set of documents is registered in ablockchain using only hash values (as opposed to in-chain storage, inwhich the documents themselves are placed into the blockchain),information regarding the relationships of the documents is typicallynot included. Therefore, any third-party verification regarding thedocuments at a later time, that involves a determination of whether thedocument owner considered the documents to be related in some manner atthe time of registration, may require that representations by thedocuments' owner be trusted at the time of verification. Although thisis a minor point, it is nevertheless at least a blemish on the idea thatblockchains provide “trust in the absence of a trusted entity”, becauseat least one aspect of the document information (i.e., the existence ofsome relationship among different documents) cannot be verified in atruly independent manner.

This can become an issue when an arrangement involves multiple separatedocuments. Some (of many) example scenarios include: (1) real estatetransactions; (2) sets of estate planning documents that includecodicils for identifying specific bequests, powers of attorney, andothers; (3) financial transactions involving multiple stages and/oraccounts; and (4) patent cross-license deals with one document thataddresses standard essential patents (SEPs) licensing terms, and aseparate document that addresses patent licensing terms for non-SEPs.Patent cross-license deals may use separate documents because laws andtypical licensing terms can differ widely regarding SEP and non-SEPlicensing terms, and companies may become involved in a lawsuit over oneclass of patents, while the other class is covered by an existinglicense. The use of multiple documents in real estate transactions andestate planning is well-known. It would therefore, be beneficial to beable to identify that, at the time documents were registered in anoff-chain storage blockchain (e.g., a blockchain that stored onlydocument hash values, rather than the documents themselves), thedocuments were related as part of an identified set of documents.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding of the present invention, reference isnow made to the following descriptions taken in conjunction with theaccompanying drawings, in which:

FIG. 1A illustrates the Public Electronic Document Dating List (PEDDaL®)blockchain.

FIG. 1B illustrates an equivalent representation of the PEDDaL®blockchain.

FIG. 2 illustrates a public record that establishes a no-later-thandate-of-existence for a PEDDaL® block.

FIG. 3 illustrates generation of blockchain records.

FIG. 4 illustrates generation of a block with daisy chained recordreferences.

FIG. 5 illustrates fields of an exemplary blockchain record with daisychained record references.

FIG. 6 illustrates linked record fields for a plurality of blockchainrecords.

FIG. 7 illustrates a linking map of daisy chained blockchain records.

FIG. 8 illustrates a blockchain submission with linking instructions.

FIG. 9 illustrates a flowchart of operations associated with generatinga blockchain with daisy chained record references.

FIG. 10 illustrates another flowchart of operations associated withgenerating a blockchain with daisy chained record references.

FIG. 11 illustrates a flowchart of operations associated with generatinga linking map of daisy chained blockchain records.

FIG. 12 illustrates a flowchart of operations associated with verifyingintegrity and a no-later-than date-of-existence for a document.

FIG. 13 illustrates a secure document corral that can be used with theblockchain of FIGS. 1A and 1B.

FIG. 14 illustrates a flowchart of operations associated with using ablockchain with a document corral.

FIG. 15 illustrates a secure document corral with a quarantinecapability that enhances the secure document corral of FIG. 13 .

FIG. 16 illustrates scenarios of blockchains being in compliance ornon-compliance of legal requirements.

FIG. 17 illustrates a flowchart of operations associated with using ablockchain with a quarantine-capable document corral.

FIG. 18 illustrates the use of a network message for timestamping ablock.

FIG. 19 illustrates a timeline of using network messages fortimestamping a block in a blockchain.

FIG. 20 illustrates the use of a digital evidence bag (DEB) with ablockchain.

FIG. 21 illustrates a flowchart of operations associated with usingnetwork messages for timestamping a block in a blockchain.

FIG. 22 illustrates an arrangement of data for self-addressed blockchainregistration (SABRe).

FIG. 23 illustrates additional detail an arrangement of data for aSABRe-enabled blockchain.

FIG. 24 illustrates a flowchart of operations associated with using aSABRe-enabled blockchain.

FIG. 25 is a block diagram of an example computing device suitable forimplementing some of the various examples disclosed herein.

Corresponding reference characters indicate corresponding partsthroughout the drawings.

DETAILED DESCRIPTION OF THE INVENTION

The various examples will be described in detail with reference to theaccompanying drawings. Wherever possible, the same reference numberswill be used throughout the drawings to refer to the same or like parts.References made throughout this disclosure relating to specific examplesand implementations are provided solely for illustrative purposes but,unless indicated to the contrary, are not meant to limit all examples.

Systems and methods are disclosed which use a blockchain (a.k.a. blockchain or edition chain) to enable the establishment of integrity andno-later-than date-of-existence for documents (e.g., generic computerfiles) even for documents held in secrecy and those stored inuncontrolled environments. Daisy chained records permit linking variousblockchain records, to establish that relationships between the variousdocuments (represented by the records) had been asserted as of the dateof registration (in the blockchain) of the documents. Example uses thatmay advantageously employ a blockchain with daisy chained recordreferences include real estate transactions, estate planning, contractnegotiations, financial transactions involving multiple stages and/oraccounts, and complex deals that aggregate multiple individualdocuments.

A permissioned blockchain with off-chain storage establishes integrityand no-later-than date-of-existence for documents, leveraging records inwhich hash values represent documents. After registration, if adocument's integrity or date is questioned, the document is hashed againand the new hash value is compared with the record. A provabledate-of-existence for the block containing the record establishes ano-later-than date-of-existence for the document. Using multiple hashvalues renders preimage attacks into multi-dimensional problems,increasing security against quantum computing. If there is no challengeto the document, the document may remain private (confidential)indefinitely. Even if disclosure is needed to prove the document's ageand integrity, in some scenarios, disclosure can be limited to an agreedset of trustworthy parties, without becoming public. Compact records andoff-chain storage in a secure document corral preserve documentconfidentiality and ease storage burdens for the distributed blockchain.Permissioning monetizes operations and enforces record content rules,avoiding problematic material (e.g., obscene material, material posingprivacy problems, intellectual property rights violations, and digitalfiles containing malicious logic) to ensure long-term viability. Thatis, the permissioning entity can bar blockchain entries that containmaterial other than hashes, timestamps, and other authorized datafields, in the correct location with proper content. Thus, obscene andillegal material can be kept out. Additionally, the permissioning entitycan limit submissions to submitters who have paid the required feeand/or belong to the proper group (e.g., industry sector) that isserviced by the blockchain. The priority parent application precededBitcoin; earlier terms for “block” and “block chain” are “edition” and“edition chain.” Daisy chaining records establishes that relationshipsexisted among various documents as of the blockchain registration datesand can be used to identify when a set of documents, that had beenregistered in a blockchain with an indication of a relationship amongthe set, is missing one or more of the documents.

Additional benefits of the disclosure include a blockchain for whichdocument protection persists beyond the cessation of operations by anybusiness associated with producing the blockchain. No one involved withthe disclosed blockchain can either falsify date proof (of any documentthat did not actually exist as of the provable date-of-existence) ordeny date proof for any document with a corresponding record appearingwithin the blockchain. Thus, any employee of a permissioning entitybeing accused of corruption does not taint the proofs offered by theblockchain. Verification of a no-later-than date of existence for adocument can be accomplished by anyone, without the need for specialsoftware to read the blockchain or locate records—contingent only on acopy of the document at issue being available for hashing. Thus, whencombined with the off-chain storage, significantly reduced storagerequirements, and the benefits of the permissioning entity precludingproblematic material, a long-life blockchain is possible. Additionaldisclosure assists with keeping blockchain operations compliant withlegal requirements when an enforceable court order requires deletion ofcertain material (e.g., a “right to be forgotten” as identified in theGeneral Data Protection Regulation (GDPR)). Such compliance ischallenging, if not possible for on-chain storage blockchains, such asused by Bitcoin and Ethereum.

The daisy chain capability enhances other aspects of the disclosure,such as the use of a document corral, a document quarantine (for itemsnot permitted to remain within a document corral), the use of parallel(different speed) blockchains, and a unique self-addressed blockchainregistration (SABRe) capability that enables a document to identify thelocation of its record within a blockchain, and yet still produce a hashvalue (message digest) that is within the record it references. Daisychaining enables identification of sets of documents within a documentcorral, without either bloating the blockchain or requiring an externaldata item to track. Daisy chaining also enables identification of thedisposition of quarantined documents. Further, daisy chaining alsoenables identifying an earlier date-of-existence for “early” documentsthat leverage the advantageous SABRe capability.

Although various novel concepts are introduced separately, they arecompatible with each other. Therefore it is specifically contemplatedthat combinations will be formed, such as by intermixing ideas andcomponents introduced by any of the figures. That is, examplesassociated with FIGS. 1A-3 may be combined with one or more portions ofany ideas associated with the other figures.

FIG. 1A and FIG. 1B illustrate the Public Electronic Document DatingList (PEDDaL®) blockchain in differing representations. FIGS. 1A and 1Bshould be viewed together for the following description: A permissioningentity 101 generates a blockchain 100 on a schedule for the benefit ofsubmitters 131, 132, and 133. Permissioning entity 101 is named so,because it grants permission for records to be included withinblockchain 100. Reasons for using a permissioning entity includemonetizing the blockchain, by permitting only paying submitters to addto blockchain 100, and enforcing record content (e.g., ASCII hexcharacters only, with 256-character record lengths), to precludepotentially problematic material (e.g., obscene material, materialposing privacy problems, intellectual property rights violations, anddigital files containing malicious logic) from entering blockchain 100.

A primary difference between a permissioning entity and a trusted entityis that, whereas a trusted entity (e.g., a trusted timestamping entity,document escrow agent) must be trusted to represent critical factstruthfully and accurately, in order to establish a no-later-thandate-of-existence and integrity for a challenged document, there is noneed to trust a permissioning entity. For scenarios in which a trustedentity is needed, document challengers and arbiters must trust thetrusted entity and, if the trusted entity's assertions are incorrect(i.e., the trusted entity is dishonest or even simply making an honesterror) the trusted entity might falsify the proof—either improperlydenying a correct no-later-than date-of-existence and integrity for adocument, or improperly attesting to an incorrect no-later-thandate-of-existence and integrity for a document. For scenarios in which atrusted entity is not needed, but a permissioning entity is needed,failures by the permissioning entity, whether due to dishonesty orsimple mistake, result in significantly less serious consequences: arecord is not entered into the blockchain in a timely manner, and/orrecords are entered into the blockchain that fail the criteria forinclusion.

If a permissioning entity makes repeated mistakes of not includingrecords in a timely manner, the utility of the blockchain for protectingthe documents already registered is not lessened. Document owners, whohave already registered documents, are still safe. New documents can besubmitted to a different blockchain with, hopefully, a betterpermissioning entity. In stark contrast, for trust arrangementsrequiring the use of a trusted entity, a single act of dishonesty by thetrusted entity can threaten the protection of all documents. Documentowners, who have already registered documents, may lose all theirability to establish no-later-than dates-of-existence and integrity fortheir registered documents. This is a tragic situation, and a seriousrisk presented by using trust mechanisms that rely on trusted entities.

Another difference between a permissioning entity and a trusted entityis that, if the trusted entity ceases operations, document owners, whohave already registered documents, may lose all their ability toestablish no-later-than dates-of-existence and integrity for theirregistered documents in this scenario, also. In stark contrast, if apermission entity ceases operations, the consequence is limited todocument owners not being able to register new documents into theblockchain whereas, for previously-registered documents, no-later-thandates-of-existence and integrity remain safely verifiable. Thus, thereis an additional risk factor for systems that use trusted entities, towhich systems that need only permissioning entities are not susceptible.The basic issue is that trust in a trusted entity is critical, because atrusted entity can affect proof regarding already-registered documents,whereas a permissioning entity cannot affect proof regardingalready-registered documents, in the examples disclosed herein.

Description of blockchain 100 will begin with an intermediary block 102b, that is neither the initial block nor the final block in blockchain100. In some examples, the operations described herein, associated withblockchain 100, are performed using one or more computing devices 2500of FIG. 25 . Block 102 b includes records 104 a, 104 f, 104 g, and 104h. Record 104 a represents prior block 102 a, and is used to chain block102 a with block 102 b. Block 102 a is hashed with an integrityverification code (IVC) generator 108 to generate hash value 110 a. Insome examples, and IVC comprises a complete message digest; in someexamples, an IVC comprises a partial message digest; in some examples,an IVC comprises two message digests; and in some examples, an IVCcomprises a mixture of partial and complete message digests. In someexamples, hash value 110 a includes one or more of the Secure HashAlgorithm 512 (SHA-512) message digest, the SHA-1 message digest, andthe SHA-256 message digest. The use of multiple message digests rendersblockchain 100 more resistant to second preimage attacks, which maybecome a threat to some blockchains in the era for quantum computers andquantum computing. It should be understood that hash value 110 a mayalternatively represent any value that can indicate integrity of adigital bit stream, such as cyclic redundancy checks, checksums, andothers. In order to establish a no-later-than date-of-existence forblock 102 a, hash value 110 a is published in a public record 112 a, forexample in an advertisement in a printed publication. In some examples,the Marketplace section of classified advertisements in the USA Todaynewspaper is used a public record.

Multiple documents 106 f, 106 g, and 106 h are to be registered inblockchain 100, specifically, block 102 b. Therefore, each of documents106 f, 106 g, and 106 h is hashed (or some other integrity verificationcode operation is performed) by IVC generator 108 to generate hashvalues 110 f, 110 g, and 110 h, respectively. These are then enteredinto records 104 f, 104 g, and 104 h, respectively, as is described infurther detail with respect to FIGS. 3, 4, 9 and 10 . Block 102 b isthen closed, which means that no further records can be added, andpublished in one or more public locations, such as on a website 140 (seeFIG. 1B) and/or transmitted to a plurality of dispersed blockchainnodes. Also, in some examples, block 102 b is written to a fixed media142 b, such as a DVD, and distributed (see FIG. 1B). Distribution offixed media 142 b may include sending copies to submitters 131, 132, whosubmitted records to block 102 b, as well as other archival locations,such as libraries and document archival services.

Block 102 b is then hashed by IVC generator 108 to generate hash value110 b, which is entered into record 104 b in a block 102 c. Block 102 cis subsequent to block 102 b, and record 104 a, which represents block102 b, is used to chain block 102 b with block 102 c. Additionally, inorder to establish a no-later-than date-of-existence for block 102 b,hash value 110 b is published in a public record 112 b, for example inanother advertisement in a printed publication. In some examples, publicrecord 112 a and public record 112 b are published the same day (e.g.,separate classified ads in the same newspaper edition). In someexamples, public record 112 a and public record 112 b are published ondifferent days, with public record 112 b following public record 112 a.

The process repeats for documents 106 k, 106 m, and 106 n to beregistered in blockchain 100, specifically, block 102 c. Therefore, eachof documents 106 k, 106 m, and 106 n is hashed by IVC generator 108 togenerate hash values 110 k, 110 m, and 110 n, respectively. These arethen entered into records 104 k, 104 m, and 104 n, respectively. Block102 c is then closed and published in one or more public locations, suchas on a website 140 and/or transmitted to a plurality of dispersedblockchain nodes. Also, in some examples, block 102 b is written to afixed media 142 c, such as a DVD, and distributed (see FIG. 1B).Distribution of fixed media 142 c may include sending copies tosubmitter 133, who submitted a record to block 102 c, as well as otherarchival locations, such as libraries and document archival services.Block 102 c is then hashed by IVC generator 108 to generate hash value110 c, which is entered into a record (not illustrated) in a block 102d. Block 102 d is subsequent to block 102 c, and the record whichrepresents block 102 c, is used to chain block 102 c with block 102 d.Additionally, in order to establish a no-later-than date-of-existencefor block 102 c, hash value 110 c is published in a public record 112 c,for example in another advertisement in a printed publication. In someexamples, public record 112 b and public record 112 c are published thesame day (e.g., separate classified ads in the same newspaper edition).In some examples, public record 112 b and public record 112 c arepublished on different days, with public record 112 c following publicrecord 112 b.

FIG. 2 illustrates a public record 112 that establishes a no-later-thandate-of-existence for a PEDDaL® block, specifically a block identifiedas 090310 a, which existed no later than Mar. 19, 2009. Public record112 is a real public record for a real block. Therefore, the PEDDaL®blockchain is able to prove a no-later-than date-of-existence for filesas early as Mar. 19, 2009. A classified ad 212 includes a hash value110, which is the SHA-512 message digest, followed by the SHA-1 messagedigest for PEDDaL® block 090310 a. The block identification is shown ina field 202; a field 204 indicates a website (for example, website 140of FIG. 1B) where a copy of PEDDaL® block 090310 a can be obtained. Agenerator version field 206 indicates a generator version used togenerate hash value 110. Using the generator version information, thespecific hash functions used can be identified. When different hashfunctions are used, the generator version information will change,although it is possible for the generator version information willchange even when the hash functions used remain unchanged.

A date field 208 indicates the date of publication of public record 112,and therefore, establishes the no-later-than date-of-existence for aPEDDaL® block 090310 a as Mar. 19, 2009. Because the specific publicrecord (classified ad 212 within the USA Today newspaper) was publishedto large base of readers, who would have noticed if date field 208 hadbeen incorrect, after publication and distribution, the date in datefield 208 became a trustworthy date.

FIG. 3 illustrates generation of blockchain records 104 p, 104 q, 104 r,104 s, and 104 t (104 p-104 t) from documents 106 p, 106 q, 106 r, 106s, and 106 t (106 p-106 t), respectively, using a record generator 308.The generation of other records shown in other figures herein (e.g.,records 104 a-104 d, 104 f-104 h, 104 k, 104 m, and 104 n) is similar.Document 106 p is hashed by IVC generator 108 within record generator308, to produce hash value 110 p. An administrative data generator 302,also within record generator 308, generates administrative data 310 p.Exemplary administrative data 310 p includes a generator version number,a timestamp, and other data. Hash value 110 p and administrative data310 p are combined (e.g., concatenated) to produce record 104 p. Asillustrated, records 104 q-104 t are generated similarly. A recordidentifier 304 p is a unique identifier for record 104 p. In someexamples, record identifier 304 p is the first hexadecimal octet of aSHA-1 message digest for document 106 p. In some examples, recordidentifier 304 p is used as a root filename for record 104 p, combinedwith a file type extension such as, for example, “.pdl”. There are alsoequivalent record identifiers 304 q, 304 r, 304 r, and 304 t, forrecords 104 q, 104 r, 104 r, and 104 t, respectively. Other records andrecord identifiers mentioned herein have a similar relationship.

FIG. 4 illustrates generation of a block 102 e with daisy chained recordreferences. Records 104 p-104 t are received and provided to a blockgenerator 408 (using record identifiers 304 p-304 t as filenames forrecords 104 p-104 t), along with linking instructions 802 e, describedin more detail with respect to FIG. 8 . Block generator 408 identifieshash values 110 p-110 t and administrative data 310 p, 310 q, 310 r, 310s, and 310 t in records 104 p, 104 q, 104 r, 104 s, and 104 t,respectively. An administrative data generator 404 uses administrativedata 310 p-310 t to generate new administrative data 410 p, 410 q, 410r, 410 s, and 410 t, which may replace and/or add to information inadministrative data 310 p-310 t. For example, a record index is added,and a digitally signed timestamp may also be added to indicate the timeat which block 102 e is compiled by block generator 408. Additionally, alinked record field is populated with linked record values, inaccordance with linking instructions 802 e. The updated records 104p-104 t, having hash values 110 p-110 t and administrative data 410p-410 t (in place of administrative data 310 p-310 t), are placed intoblock 102 e. In some examples, record generator 308 intakes linkinginstructions 802 e and generates records with linked record fieldalready populated with linked record values. Thus, either recordgenerator 308 or block generator 408 may populate linked record fieldswith linked record values.

FIG. 5 illustrates fields of an exemplary blockchain record with daisychained record references, specifically record 104 p. As illustrated,record 104 p is in a first defined format that includes hash value 110 pfollowed by administrative data 410 p, although other formats arepossible. In some examples, the first format has a fixed number ofbytes, such as 256 bytes. As indicated, hash value 110 p includes aSHA-512 message digest (a first IVC value) in a first IVC portion 506 p,followed by a SHA-1 message digest (a second IVC value) in a second IVCportion 508 p (both for document 106 p). This combination is 168 byteslong on machines having 4-bit bytes in the ASCII text file format, sincethe SHA-512 message digest is 512 bits and the SHA-1 message digest is160 bits. Producing blockchain records and blocks in ASCII text fileformat doubles their size, relative to a binary file format, but permitsinspection of the contents of both records and blocks with any ASCIItext viewer, thereby precluding the need for proprietary software whenindependently verifying document registrations. It should be understoodthat other hash functions may also be used, for example SHA-256, andthat some examples may use only a single IVC (hash value) or more thantwo IVCs. As used within record 104 p, hash value 110 p is an IVC fieldthat has a first IVC value portion 506 p a second IVC portion 508 p.

Administrative data 410 p includes generator version information 510 p,a first timestamp in a first timestamp field 512 p, a second timestampin a second timestamp field 514 p, other administrative data 516 p, alinked record locator field 502 p, and an index value in an index field5004 p. In some examples, second timestamp field 514 p contains anencrypted timestamp from a trusted timestamping entity (a.k.a. trustedtimestamping authority, TTA), for example encrypted with the trustedtimestamping entity's private key, as a form of a digital signature ofthe timestamp. The index is to assist locating records within specificblocks. Together, a block identification and a record index specify ablockchain address 518, which provides the location of a record withinblockchain 100. In some examples, record 104 p has the following formatin ASCII text:

-   -   Characters 1-128: SHA-512 message digest (representing 512        bits);    -   Characters 129-168: SHA-1 message digest (representing 160        bits);    -   Characters 169-170: 2-digit (hex) generator version        (representing 8 bits);    -   Characters 171-178: 8-digit (hex) timestamp (representing 32        bits);    -   Characters 179-198: 20-digit padding with the ASCII character        for zeros (reserved for future use);    -   Characters 199-250: linked record locater field, 4×13-digit        linked record locators; and    -   Characters 251-256: 6-digit (hex) index of the position within        the block (document dating list edition (in DDL file), using        1-based indexing.

Linked record locator field 502 p indicates linked record values thatindicate the location of other records (or a portion of the contents ofthe other records) in blockchain 100, and possibly also in differentblockchains (i.e., blockchains other than blockchain 100). As indicated,linked record locator field 502 p has a flag 520 q, an index 504 q, aflag 520 r, an index 504 r, a flag 520 k, a block identification 522 c,and an index 504 k. Flag 520 q indicates that the next bit field,containing index 504 q indicates an index within the same block.Similarly, flag 520 r also indicates that the next bit field, containingindex 504 r indicates an index within the same block. Index 504 q is theindex for record 104 q, and index 504 r is the index for record 104 r.As can be seen in FIG. 4 , records 104 p, 104 q, and 104 r are allwithin the same block 102 e. Optional flag 520 k indicates that the nextbit field, block identification 522 c, indicates a different block thanblock 102 e, so the next bit field, index 504 k indicates an indexwithin the referenced block. Index 504 k is the index for record 104 k,and block identification 522 c holds the block identification of block102 c. As can be seen in FIG. 1 , record 104 k is within block 102 c. Insome examples, flags are optional. As one example, flags 520 q and 520 rcomprise seven zeros to indicate that indices 504 q and 504 r are forrecords within the same block. Block ID 522 c having non-zero valuesacts as sufficient indication that index 504 k is for a different block,rendering flag 520 k superfluous for this particular scheme.

In some examples, the flags may be combined with the blockidentification, such as by having a format with two bit fields: one forthe block identification and one for the index. If the index is withinthe same block (e.g., the case for flags 520 q and 520 r, describedabove), the bit field for the block identification is padded with zeros.If the index is not within the same block (e.g., the case for flag 520k), the bit field for the block identification is populated with theblock identification, which will be different than all zeros. Thus, insome examples, the flags are not dedicated bit fields, but are insteadinferred from whether the block identification is padded with zeros orfilled with non-zero values. In some examples, a flag indicating thatthe index is within the same block is shorter, such as a singlecharacter, for example the ASCII character for the number 0 (zero). Insome examples, linked record locator field 502 p has the followingformat in ASCII text:

-   -   Characters 199-211: 13-character linked record locator #4 (used        last);    -   Characters 212-224: 13-character linked record locator #3;    -   Characters 225-237: 13-character linked record locator #2; and    -   Characters 238-250: 13-character linked record locator #1 (used        first).

In some examples, the block identifications have the following format inASCII text: YYMMDDa=seven (7) characters. In some examples, the indiceshave the following format in ASCII text: six (6) digit (hex) integeridentifying the counted position of the record within the block. Forexample, an index of 000002 with 256-byte records (on a 1 character=1byte machine) indicates that the record starts at character 257 withinthe block. With this scheme, each linked record value is 13 characters(7+6=13), although different formats and lengths are possible.

As an example, consider a 256-byte (256-character) record having thefollowing set of characters in positions 199 through 256: “xxxxxx0000000000 00018082 5A000999 180825A0 00998000 00123456 78000333”, where xindicates unknown. The index is 0x333, indicates that these linkedrecords appear within the 333^(rd) record (in hexadecimal, 819 indecimal) in the block. The linked record locator field has three linkedrecords, two within prior blocks, and one within the same block. Thelinked records in the prior blocks are in block 180825 a, at index0x998; and in block 180825 a, at index 0x999. The index values are inhexadecimal, the decimal values are 2456 and 2457, respectively. Theexample linked record that is also within the same block is notreferenced by index value (just for this example), but is insteadreferenced by a portion of the contents of that linked record. In someexamples, the first octet (i.e., the first 8 characters) of the SHA-1message digest of the other record is used as a reference or pointer toa linked record. Specifically, that linked record has the first octetidentified as “12345678”. In order to find that linked record in thisscheme, the other records in the block are searched until a record isfound that contains 12345678 in the position corresponding to the first8 characters of the SHA-1 message digest. Since the octet is eight (8)characters in length, in order to preserve a 13-character scheme for alinked record locator field, the zero-padding is reduced to five (5)characters. This referencing by the first SHA-1 octet can be used whenthe index value of a linked record is subject to change. Index valuescan change if, for example, an earlier (within the block) record isremoved because of problematic content, or is a duplicate of anotherrecord.

FIG. 6 illustrates linked record locator fields 502 p, 502 q, 502 r, and502 k, for a plurality of blockchain records. Linked record locatorfields 502 p, 502 q, 502 r, and 502 k will be used to generate a linkingmap 700 of daisy chained blockchain records, as shown in FIG. 7 . Linkedrecord locator field 502 p contains links to records 104 q, 104 r, and104 k, as noted previously. Linked record locator field 502 q has a flag520 p, an index 504 p, flag 520 r, index 504 r, a flag 520 g, a blockidentification 522 b, and an index 504 g. Flag 520 p indicates that thenext bit field, containing index 504 p indicates an index within thesame block. Index 504 p is the index for record 104 p. Flag 520 gindicates that the next bit field, block identification 522 b, indicatesa different block, so the next bit field, index 504 g indicates an indexwithin the referenced block. Index 504 g is the index for record 104 g,and block identification 522 b holds the block identification of block102 b. As can be seen in FIG. 1 , record 104 g is within block 102 b.Linked record locator field 502 r has a flag 520 s, an index 504 s, aflag 520 t, and an index 504 t. Flag 520 s indicates that the next bitfield, containing index 504 s indicates an index within the same block.Index 504 s is the index for record 104 s. Flag 520 t indicates that thenext bit field, containing index 504 t indicates an index within thesame block. Index 504 t is the index for record 104 t. As can be seen inFIG. 4 , records 104 r, 104 s, and 104 t are all within the same block102 e. Linked record locator field 502 k is the linked record field forrecord 104 k, and has a flag 520 m, an index 504 m, a flag 520 h, blockidentification 522 b, and an index 504 h. Flag 520 m indicates that thenext bit field, containing index 504 m indicates an index within thesame block. Index 504 m is the index for record 104 m. Flag 520 hindicates that the next bit field, block identification 522 b, indicatesa different block, so the next bit field, index 504 h indicates an indexwithin the referenced block. Index 504 h is the index for record 104 h,and block identification 522 b holds the block identification of block102 b. As can be seen in FIG. 1 , record 104 g is within block 102 b. Ascan be seen in FIG. 1 , records 104 k and 520 m are both within block102 c, and records 104 h is within block 102 b.

Using this information, linking map 700 can be generated. As seen inlinking map 700, record 104 p links to records 104 q, 104 r, and 104 k,directly. Record 104 p links back to record 104 p, duplicates the linkto record 104 r, and directly links to record 104 g. Record 104 r linksto records 104 s and 104 t, directly. Record 104 k links to records 104m and 104 h, directly. Thus, record 104 p is linked through a daisychain to record 104 h. In total, nine (9) records are linked via a daisychain, even though no single record links to more than three (3) recordsdirectly. The linking handles multiple records within a block, as wellas spans multiple blocks. With this scheme, an unlimited number ofrecords can be linked across an arbitrary number of blocks, with theprimary limitation being that a particular record can only link tocontemporaneous and preceding records.

A real-world example exists for the PEDDaL® blockchain. Block 191205 acontains two records, one ending in “0000000 00002A 0000000 0000A4100109A 000004 0000000 00001F 0000A3” and the other ending in “000000000001F 0000000 0000A3 100109A 00000F 0000000 00002A 0000A4”. This meansthat the record at index 0xA3 (164 in decimal) is linked to records withindex values 0x2A, 0xA4, and 0x1F within its same block 191205 a, andalso the record at index value 0x4 in block 100109 a. Also, the recordat index 0xA4 is linked to records with index values 0x1F, 0xA3, and0x2A within its same block 191205 a, and also the record at index value0xF in block 100109 a. The records at indices 0xA3 and 0xA4 are directlylinked to each other. The record at index 0xA3 is not directly linked(first tier link) to the record at index value 0xF in block 100109 a.However, the record at index 0xA3 is daisy chained (linked via a daisychain) to the record at index value 0xF in block 100109 a, through therecord at index 0xA4. Similarly, the record at index 0xA4 is daisychained to the record at index value 0x4 in block 100109 a, through therecord at index 0xA3.

FIG. 8 illustrates a blockchain submission 800 with linking instructions802 e. Submission 800 is sent in by a submitter (a user of blockchain100, e.g., one of submitters 131, 132, and 133). In the illustratedsituation, the submitter is submitting records 104 p-104 t, along withlinking instructions 802 e that enable block generator 408 (see FIG. 4 )to construct linked record values in linked record locator fields 502 p,502 q, and 502 r (see FIG. 6 ). For example, an instruction field 806 pidentifies that it is for record 104 p, using record identifier 304 p,and that record 104 p should link to records 104 q, 104 r, and 104 k,using record identifiers 304 q, 304 r, and 304 k, respectively. Aninstruction field 806 q identifies that it is for record 104 q, usingrecord identifier 304 q, and that record 104 q should link to records104 p, 104 r, and 104 g, using record identifiers 304 p, 304 r, and 304g, respectively. An instruction field 806 r identifies that it is forrecord 104 r, using a record identifier 304 r, and that record 104 rshould link to records 104 s and 104 t, using record identifiers 304 sand 304 t, respectively. Record identifiers 304 p-304 r, 304 g, and 304k, include sufficient information for block generator 408 to generatethe flags, block identifications and indices shown in FIG. 6 , and/orthe linked record value that uses the contents of the linked records(e.g., the SHA-1 first octet).

FIG. 9 illustrates a flowchart 900 of operations associated withgenerating blockchain 100 with daisy chained record references. In someexamples, at least a portion of flowchart 900 is performed using one ormore computing devices 2500. Operation 902 includes receiving documents,and operation 904 includes determining related documents, which will belinked. Operation 906 includes generating document records, andoperation 908 includes generating linking instructions. The record andlinking instructions are submitted in operation 910 and received by apermissioning entity in operation 912. The permissioning entity receivesrecords and linking instructions from other submitters in operation 914.A current block is generated in operation 916 and closed in operation918. The closed block is published and distributed in operation 920 anda record is generated for it in operation 922. An IVC (e.g., hash value)for the closed block is published in operation 924, to enable laterproof of the date-of-existence for the closed block. The closed block ischained to the subsequent block in operation 926, by entering the recordfor the closed block into the subsequent block. Additional records andlinking instructions are received from yet other submitters in operation928, and flowchart 900 returns to operation 916, thereby iteratingoperations 916 through 928 for an arbitrary number of chained blocks.

FIG. 10 illustrates an expanded view of operation 916 in a flowchart. Asshown, operation 916 includes operations 1002 through 1024. Operation1002 includes generating a final record in a defined format from areceived record and includes operations 1004 through 1014. Operation1004 includes populating an IVC field with an IVC value; operation 1006includes populating an index field with an index value; operation 1008includes populating a generator version field with generator versioninformation; operation 1010 includes populating a timestamp field with atimestamp value; and operation 1012 includes populating anotheradministrative data field with the proper information.

Operation 1014 includes populating a linked record locator field andincludes operations 1016 through 1020. Operation 1016 includesgenerating flags to specify whether a linked record is within the sameblock or a different block. Operation 1018 includes adding blockidentification for those linked records that are in a different block.Operation 1020 includes adding a linked record value, for example arecord index or a portion of the content of the linked record (e.g., thefirst octet of the SHA-1 message digest). In some examples, adding alinked record value comprises adding a blockchain address for anotherrecord. Operation 1022 iterates operations 1016 through 1020 until alllinks are complete for the current record. Operation 1024 then iteratesoperation 1002 for all submitted records.

FIG. 11 illustrates a flowchart 1100 of operations associated withgenerating a linking map of daisy chained blockchain records. In someexamples, at least a portion of flowchart 1100 is performed using one ormore computing devices 2500. Operation 1102 includes receiving a recordcontaining links, and operation 1104 includes identifying a linkedrecord locator field. Operation 1106 includes reading the flag (sameblock or different block) for the current link. If the flag indicatesthat the linked record is in a different block, as determined indecision operation 1108, that block is retrieved in operation 1110. Thereferenced record is identified in operation 1112, and the link is usedto add the referenced record to the linking map in operation 1114.Operation 1116 iterates operations 1104 through 1114 for all the linksin the current record. Operation 1118 iterates operations 1102 through1116 for all referenced records, thereby exhausting the limits of thedaisy chained links. Operation 1120 reports the results of the linkingmap, which in some examples, is a list of all related (linked) records.Decision operation 1122 determines whether a retrieved set of documentsis complete, based on whether any daisy chained records do notcorrespond to a document in the set of documents. If any documents aremissing, operation 1124 generates an alert that one or more documents,corresponding to records identified within the daisy chain, is missing.

FIG. 12 illustrates a flowchart 1200 of operations associated withverifying integrity and a no-later-than date-of-existence for adocument. In some examples, at least a portion of flowchart 1200 isperformed using one or more computing devices 2500. A contested (orchallenged) document is received in operation 1202, and operation 1204includes generating an IVC (e.g., one or more hash values) for thedocument. Operation 1206 includes receiving block identificationinformation, and operation 1208 includes retrieving the identifiedblock. Operation 1210 includes receiving the record index, and operation1212 includes retrieving the identified record from the block, using theindex. Operation 1214 includes identifying the document IVC in therecord, and decision operation 1216 includes comparing the IVC generatedin operation 1204 with the IVC identified in operation 1214. If they aredifferent, then operation 1218 reports a failure.

If, however, the document IVC match, then operation 1220 reports successfor that first match, and operation 1222 generates an IVC for the block.The public record is identified in operation 1224 and the public recordis retrieved in operation 1226. Operation 1228 includes identifying theblock IVC in the public record, and decision operation 1230 includescomparing the IVC generated in operation 1222 with the IVC identified inoperation 1228. If they are different, then operation 1232 reports afailure. Otherwise, operation 1234 reports that the integrity of thecontested document has been verified and uses the date of the publicrecord (Retrieved in operation 1226) as the no-later-thandate-of-existence for the contested document.

FIG. 13 illustrates a secure document corral 1300 that can be used withblockchain 100. Secure document corral 1300 provides access-controlledsecure off-chain storage, in order to preserve document confidentialityand ease storage burdens for distributed copies of blockchain 100. A setof documents 106 f-106 t is held within document corral 1300. In someexamples, document corral 1300 is stored in a cloud service. In someexamples, document corral 1300 is stored in a physically securefacility, under the control of the operators of blockchain 100. In someexamples, document corral 1300 and blockchain 100 are operatedindependently, by different entities. Document corral 1300advantageously permits storage of large amounts of data, such as largenumbers of documents, large documents, or both. Users can trustdocuments 106 f-106 t within document corral 1300 merely by any testingthem against blockchain 100. In this way, blockchain 100 is able toestablish both integrity and no-later-than date-of-existence for largevolumes of data, even while blockchain 100 itself remains compact. Thereis thus no need to reproduce the all of documents 106 f-106 t on everynode that has a copy of blockchain 100 or otherwise participates in thegrowth or use of blockchain 100. Rather, documents 106 f-106 t arestored in duplication only as needed for backups (e.g., recovery fromfailures and malicious attacks, such as ransomware) and access by users(e.g., prepositioning at geographically-dispersed nodes for quickeraccess). This scheme is therefore far more practical for networkbandwidth limitations and user storage requirements, and is also moreecologically friendly due to less electricity demands, than in-chainstorage blockchains.

An access control 1302 controls read and write privileges for documentsand other data within document corral 1300. A set of users 1304 a and1304 b have both read and write privileges, as permitted by accesscontrol 1302. A read-only user 1306 has only read privileges, asenforced by access control 1302. A write-only user 1308 has only writeprivileges, as enforced by access control 1302. In some examples,write-only user 1308 enters documents into document corral 1300 that areobtained from other sources, rather than authored by write-only user1308. As illustrated, user 1304 b has a local copy 1310 of at least someof documents 106 f-106 t. It should be understood, however, that any ofother users 1304 a, 1306, and 1308 can also have local copies of atleast some of documents 106 f-106 t. Access control 102 restricts accessto document corral 1300 to only users 1302 a, 1302 b, a306, 1308, andpermissioning entity 101. In some examples, each of users 1302 a, 1302b, a306, 1308 is restricted to accessing certain directories and/ordocuments (or files) within document corral 1300. That is, in someexamples, access control 1302 does not grant a particular user access tothe entirety of document corral 1300.

A document monitor 1312 determines when documents within document corral1300 (e.g., any of documents 106 f-106 t) are new or altered andtriggers generation of a blockchain record (e.g., record 104 f) usingrecord generator 308. In some examples, permissioning entity 101 usesrecord generator 308 to generate records upon receiving an alert fromdocument monitor 1312. In some examples, a user (e.g., user 1304 b) usesrecord generator 308 to generate records upon submitting (writing)documents to document corral 1300. Upon some trigger event, such as thenumber of document records awaiting entry into blockchain 100 reaching athreshold, or a schedule, or some other trigger event, permissioningentity 101 uses block generator 408 to generate a new block thatincludes at least some of the records awaiting entry into blockchain100. Additionally, a linked record field is populated with linked recordvalues, in accordance with linking instructions, if any are provided. Insome examples, permissioning entity 101 follows at least a portion offlowchart 900 when adding a new block to blockchain 100.

Copies of blockchain 100 are then distributed among users 1302 a, 1302b, 1306, and 1308, as well as possibly also stored within documentcorral 1300 and made available to any other interested member of thepublic. It is the widespread distribution of blockchain 100, placingcopies of blockchain 100 out of the control of permissioning entity 101that renders blockchain 100 readily tamper-evident. It is thistamper-evident property that provides the trust element because, withany tampering so trivially detectable, an absence of detecting tamperingcan be interpreted as an absence of tampering having occurred.

Users 1304 a, 1304 b, and 1308 can use blockchain 100 to verify that anydocuments newly added to document corral 1300 have a correspondingrecord within a recent block in blockchain 100. This can be accomplishedeasily, merely by hashing a local copy of the document, and searchingwithin blockchain 100 for any record that contains the hash. In someexamples, permissioning entity 101 alerts the user who submitted thedocument into document corral (and also other interested parties) theblock ID (e.g., a sequential number code assigned to a block) and recordindex, so that interested parties can go straight to the identifiedrecord and verify its accuracy without having to perform a search. Ifany recently-submitted documents do not have a corresponding record,interested parties can alert permissioning entity 101, as well as otherinterested parties, about the gap, so that permissioning entity 101 ison notice of a deficiency that requires remediation.

When users 1304 a, 1304 b, and 1306 retrieve documents from documentcorral 1300, they can use blockchain 100 to verify that the documentshave not changed since the time of the earliest corresponding recordwithin blockchain 100. Any documents for which no corresponding recordexists within blockchain 100 (e.g., no record contains the hash value(message digest) of the document) are treated as unverified.Additionally, in the event that any of users 1304 a, 1304 b, and 1306retrieves a set of documents from document corral 1300, the set ofdocuments can be checked for completeness by using linked record locatorfields. (See FIGS. 5, 6, and 7 .) This can be accomplished by hashingeach document within the set and identifying corresponding records forthat set of documents. If any records identified within the daisy chainarrangement are missing from the set of corresponding records, the usercan then easily identify that a gap exists. Thus, this arrangementprovides an additional dimension of trust: Not only are the documentsthemselves trustworthy (if they pass validation using the records), butthe completeness of a given set of documents can also be trusted (if alldaisy chained references are accounted for within the set).

FIG. 14 illustrates a flowchart 1400 of operations associated with usingblockchain 100 with document corral 1300. In some examples, at least aportion of flowchart 1400 is performed using one or more computingdevices 2500. Operation 1402 includes providing a document corral (e.g.,document corral 1300), and granting external entities access to thedocument corral, based at least on permissions set for the externalentities. The associated blockchain (e.g., blockchain 100) is generatedin operation 1404. Users submit new documents and edit (alter) documentswithin the document corral in operation 1406. Additionally, a documentmonitoring component monitors for additions and alterations. In someexamples, users of the document corral are notified when their submitteddocuments are received.

New records are generated for new and altered documents in operation1408. That is, operation 1408 includes based at least upon detecting anaddition or alteration of a document within the document corral,generating a blockchain record for the document. In some examples,linking data for sets of documents is also generated. In such examples,operation 1408 includes generating a blockchain record with a linkedrecord value. In some examples, the linked record value indicates aprior version of an altered document. In some examples, the linkedrecord value indicates a second document that is related to a receiveddocument. In such examples, the document relationships would need to beidentified, such as specified by a user, electronically extracted from adata structure, or perhaps determining that both documents wereattachments to a common message or appeared in a common source location.In some examples, users of the document corral are notified when recordscorresponding to their submitted documents are generated, and at least aportion of the records (e.g., IVCs) are provided to the users.

Operation 1410 includes extending the blockchain by adding theblockchain record into a new block of the blockchain and adding one ormore new blocks to the blockchain. In some examples, operation 1410includes the activities described previously for operations 916-926 offlowchart 900. A trigger event can be used for operation 1410, such as athreshold number of new records awaiting entry into the blockchain, or aschedule, or some other event. In some examples, users of the documentcorral are notified when records corresponding to their submitteddocuments are placed into the blockchain, and blockchain addresses forthe records are provided to the users. Operation 1412 includesdistribute copies of the blockchain outside the control of thepermissioning entity (e.g., permissioning entity 101 of FIG. 1B), sothat the permissioning entity is unable to alter the blockchain withoutdetection. In some examples, distributing copies of the blockchainoutside the control of a permissioning entity of the blockchaincomprises publishing the blockchain on a website. In decision operation1414, users and other external interested parties verify that newlysubmitted or altered documents have corresponding records. If any aremissing, an alert is generated for the permissioning entity and others(to ensure that the permissioning entity's activities are properlyscrutinized), in operation 1416. At this point, the permissioning entityshould correct the omission, which is checked in decision operation1418. If the permissioning entity fails to correct the omission,affected users should find a blockchain managed by a differentpermissioning entity, as operation 1420, and start again at operation1402 with the new blockchain, document corral, and permissioning entity.

Users retrieve documents from the document corral, either individuallyor in sets, in operation 1422. Operation 1424 includes validatingindividual documents according to flowchart 1200, or some other similarprocess. In operation 1426, users ensure that the set of documentsretrieved is complete. Users can traverse the linked record locatorfields (if applicable) to rebuild a daisy chain of documentrelationships, as described for operations 1102-1120 of flowchart 1100.The set of documents is compared with the reported linking map results,in operation 1428. The completeness of the set is determined in decisionoperation 1430, and if any documents are missing, an alert is generatedin operation 1432. The alert may be sent to permissioning entity, thespecific user, and even others, in an attempt to ensure that theoperations of document corral 1300 are subjected to proper scrutiny.

FIG. 15 illustrates a secure document corral 1300 with a quarantine 1500that enhances security over the arrangement shown in FIG. 13 . Forclarity, not all elements of FIG. 13 are reproduced in FIG. 15 ,although it should be understood that any components or capabilitydescribed for FIGS. 1-14 may also be available for the arrangement shownin FIG. 15 . User 1304 a (or another user) has placed document 106 tinto document corral 1300, and a record 1510 t for document 106 t iswithin blockchain 100, specifically, within block 102 a at index 1512 t.The block ID of block 102 a and the value of index 1512 t form anaddress of record 1510 within blockchain 100.

A trigger event has identified document 106 t as problematic. Forexample, document 106 t may have material that comprises privacyviolations, intellectual property rights violations, malicious logic,and/or obscenity. Triggers may include periodic scans, the addition ofnew documents into document corral, or events such as user 1304 a oranother entity (e.g. permissioning entity 101) is provided a notice froma law enforcement authority, a court, an attorney, or source indicatingthat distribution of document 106 t will create a legal liability.Alternatively, a scanner 1520 monitors documents (e.g., document 106 t)within document corral 1300 for quarantine triggers, for example, byscanning the documents for problematic material. In some examples,quarantine triggers are selected from the list consisting of: privacyviolations, intellectual property rights violations, malicious logic,and obscenity.

Scanner 1520 identifies that document 106 t is to be quarantined on itsown, or by user 1304 a flagging document 106 t to scanner 1520. Based atleast upon determining that document 106 t is to be quarantined, scanner1520, or another suitable component, moves document 106 t into documentquarantine 1500, which provides quarantine storage capability. That is,scanner 1520 (or some other suitable component) removes document 106 tfrom document corral 1300 and places a copy within document quarantine1500. Scanner 1520 then also forwards a copy of document 106 t to acleaner 1522 to generate document 106 u as a replacement for document106 t in document corral 1300. In some examples, cleaner 1522 generatesdocument 106 u from document 106 t by removing material that triggeredquarantine. In some examples, cleaner 1522 generates document 106 u as asummary of document 106 t.

Document 106 u is thus a cleaned version of document 106 t, whichrepresents document 106 t, and is placed into document corral 1300.Document 106 u should therefore not trigger quarantine. Records 1510 uis generated for document 106 u using record generator 308 and blockgenerator 408, and added into blockchain 100 (in block 102 d at index1512 u). Record 1510 u has linking information in a linked record field1514. In some examples, linked record field 1514 is the same format aslinked record locator field 502 p of FIG. 5 . This provides ano-later-than date-of-existence for document 106 u, which is a provabledate for a clean version of document 106 t. Cleaner 1522 provides therelationship information for documents 106 t and 106 u to across-reference component 1524, which generates linking instructions(e.g., linking instructions 802 e) to place into linked record field1514. As indicated, linked record field 1514 indicates the blockchainaddress of record 1510 t. In some examples, linked record field 1514also includes identification of document 106 t and/or a quarantinelocation (e.g., document quarantine 1500) of document 106 t. Thisquarantine process may be recursive. For example, if quarantineconditions change to include material within document 106 u, document106 u may be moved into document quarantine 1500 and this processrepeated using a new cleaned version of document 106 u.

In some examples, a cleaned reference document 106 v permits rapid crossreferencing of documents 106 t and 106 u. For example, cleaned referencedocument 106 v may include document identifiers (e.g., document names)for both documents 106 t and 106 u, along with an annotation thatdocument 106 t is the original document, which is now stored in documentquarantine 1500, and document 106 u is the replacement in documentcorral 1300. In some examples, cleaner 1522 generated cleaned referencedocument 106 v. In some examples, cleaned reference document 106 vincludes at least one item selected from the list consisting of:identification of document 106 t, identification of a quarantinelocation (e.g., document quarantine 1500) of document 106 t, ablockchain address of record 1510 t, identification of document 106 u,and a blockchain address of record 1510 u. In some examples, cleanedreference document 106 v is created or updated after record 1510 u isplaced into blockchain 100, so that the address of record 1510 u isknown. In some examples, one cleaned reference document is generated foreach pair of quarantined and cleaned documents. In some examples, acleaned reference document contains identification of multiple pairs ofquarantined and cleaned documents, and is appended with new pairs, asmore documents go into document quarantine 1500.

With document 106 t having been removed from document corral 1300,proving the integrity and no-later-than date-of-existence for document106 t requires additional work. In one example, for example if document106 t had contained malware rather than illegal material, user 1304 amay be willing to retrieve a copy of document 106 t from documentquarantine 1500 via access control 1502. This may be the case, forexample, if since the time that document 106 t had been placed intodocument quarantine 1500, the anti-virus (or other malware protection onthe computer of user 1304 a) had improved sufficiently that document 106t no longer presents a significant threat. For security, though accesscontrol 502 for document quarantine 1500 may be more stringent, such aswith fewer authorized users and/or a stricter authentication scheme,than access control 1302 for document corral 1300.

In some scenarios, user 1304 a cannot or prefers to not access document106 t in document quarantine 1500. A trusted entity 1504, however hasaccess to document quarantine 1500 and can retrieve it for verifyingthat it matches record 1510 t. That is, trusted entity 1504 establishesa no-later-than date of existence for document 106 t using blockchain100 by generating an IVC for document 106 t; comparing the generated IVCfor document 106 t with a recorded IVC within record 1510 t withinblockchain 100; and reporting a no-later-than date of existence for anearliest block (e.g., block 102 a) that contains the recorded IVC. Insuch scenarios, however, it may be required that a document challengeror arbiter accept the reporting of trusted entity 1504. Although thismay be an imperfection in the concept of a blockchain providingself-evident proof, in this manner, even documents containingproblematic material can have a version of a provable no-later-thandate-of-existence.

In some examples, documents are submitted to scanner 1520 prior to beingplaced into document corral 1300. In the illustrated scenario, document106 w is submitted to scanner 1520 and goes straight into documentquarantine 1500 without first being placed into document corral 1300. Inthis scenario, a cleaned document 106 x, representing document 106 w butwithout the problematic material, is placed into document corral 1300.

FIG. 16 illustrates scenarios of blockchains being in compliance ornon-compliance of legal requirements. Four scenarios are presented. Inscenario 16001, an in-chain storage blockchain 1600 a holds a copy ofdocument 106 t in block 1602 a. That hash value (hash function messagedigest) of block 1602 a is calculated by hashing the combination of atleast documents 106 t and 106 y. This value is stored as hash value 1612a in block 1602 b. The hash value of block 1602 b is calculated byhashing the combination of at least hash value 1612 a and document 106z. This value is stored as hash value 1612 b in block 1602 c, which isshown as holding document 106 zz.

However, document 106 t is subject to a court order or law enforcementrequirement to destroy all copies. For example, document 106 t may be aprivacy violation or obscene material. Document 106 t is removed fromall copies of blockchain 1600 a. The result is that hashing block 1602 anow produces a hash value that no longer matches hash value 1612 a. Thisbreaks the chain because block 1602 a can no longer be proven to haveexisted prior to the calculation of hash value 1612 b. Unfortunately,document 106 t is not the only document negatively affected. Withoutbeing able to prove the location of the modified version of block 1602 a(the version missing document 106 t) within blockchain 1600 a, the valueof having placed document 106 y within blockchain 1600 a is alsodamaged. The removal of documents from an in-chain storage blockchainthreatens to destroy the protection for all documents within the sameand earlier blocks.

In scenario 16002, an in-chain storage blockchain 1600 b is similarlyconfigured and holds a copy of document 106 t in block 1602 a. However,knowing the effect that removing document 106 t had on blockchain 1600a, the community that maintains blockchain 1600 b does not removedocument 106 t, despite the court order or law enforcement requirement.Anyone possessing a copy of blockchain 1600 b (at least the portion thatincludes block 1602 a) is committing a legal violation. The prospectsindicated in scenarios 16001 and 16002 can thus threaten the long termviability of in-chain storage blockchains.

In contrast, for scenario 16003, when document 106 t is removed fromdocument corral 1300, blockchain 100 is unaffected and thereforeunbroken. The record for document 106 t cannot be used to recreate theproblematic content, and so does not require removal. Although theprotection of document 106 t that had been provided by blockchain 100 isnow gone, blockchain 100 is in legal compliance, and the no-later-thandates of existence for documents 106 y, 106 z and 106 zz can still beproven. Scenario 16004 involves moving document 106 t into documentquarantine 1500, rather than merely deleting it. If document quarantine1500 is handled properly, such as by storing documents outside thejurisdiction of the relevant court or law enforcement agency, or perhapsby operating document quarantine 1500 in a manner that is blessed by therelevant court or law enforcement agency, the proof for document 106 tmay yet persist, even with legal compliance.

FIG. 17 illustrates a flowchart 1700 of operations associated with usingblockchain 100 with a quarantine-capable version of document corral 1300(e.g., with document quarantine 1500), as shown in FIG. 15 . In someexamples, at least a portion of flowchart 1700 is performed using one ormore computing devices 2500. Operation 1702 includes providing adocument corral, a document quarantine, and access to users. In someexamples providing access to the document quarantine includes providingaccess to a trusted entity. A first document is received at 1704. Insome examples, the received first document is placed into the documentcorral, in operation 1706. Operation 1708 then includes generating afirst blockchain record for the first document and adding the firstblockchain record into the blockchain. Operation 1710 includesmonitoring documents within the document corral for quarantine triggers.In some examples, quarantine triggers are selected from the listconsisting of: privacy violations, intellectual property rightsviolations, malicious logic, and obscenity.

In some examples, however, the received first document is not placedinto the document corral until after it has been checked for quarantinetriggers. In such examples, operation 1710 follows operation 1704.Decision operation 1712 determines whether the first document is to bequarantined. If not, flowchart 1700 returns to operation 1706, in whichthe first document is placed into the document corral or permitted toremain there. Even though a trigger condition has not yet beenidentified, it is possible that a trigger condition may arise in thefuture.

If decision operation 1712 identifies that the first document is to bequarantined, operation 1714 includes, based at least upon determiningthat the first document is to be quarantined, moving the first documentinto the document quarantine. In some examples, this includes removingthe first document from the document corral. A cleaned document isgenerated in operation 1716. For example, operation 1716 includesgenerating a second document as a replacement for the first document inthe document corral, the second document not triggering quarantine. Insome examples, generating the second document from the first documentincludes removing material that triggered quarantine. In some examples,the second document is a summary of the first document.

Operation 1718 includes generating a second blockchain record for thesecond document and adding the second blockchain record into theblockchain. In some examples, generating a second blockchain record forthe second document includes generating a blockchain record with alinked record value. In some examples, the linked record value indicatesa blockchain address of the first record. In some examples, the linkedrecord value indicates the first document. In some examples, the linkedrecord value indicates quarantine storage. Operation 1720 includesgenerating a cleaned reference document. In some examples, the cleanedreference document includes at least one item selected from the listconsisting of: identification of the first document, identification of aquarantine location of the first document, a blockchain address of thefirst record, identification of the second document, and a blockchainaddress of the second record.

At this point, the conditions are set for later proving integrity andno-later-than dates of existence for at least the first (quarantined)and second (cleaned) documents. The cleaned reference document may alsobe set up for date proof, although its value is less than establishingits age than in permitting rapid identification and/or location of oneof the first and second documents from the other. The date proof issimilar as has been described earlier for proving ages and integrity fordocuments and traversing a daisy chain. Operation 1722 includesretrieving the second document from the document corral and determiningintegrity or a no-later-than date of existence for the second documentusing the blockchain. The date proof of the second document may,however, be less important than the date proof of the first document,and so may be skipped in some examples.

Operation 1724 includes identifying, within a linked record locatorfield of the second blockchain record, a linked record value for thefirst document. In some examples, this is the first blockchain record,whereas in some examples, it is another locator or document identifier.Once the first document is located, operation 1726 includes retrievingthe first document from the document quarantine. Operation 1728 includeslocating the first blockchain record within the blockchain anddetermining a no-later-than date of existence for the first documentusing the blockchain and the first blockchain record. In some examples,a normal user retrieves the first document from the document quarantineand determines the date, hopefully without encountering problems relatedto the reason for the quarantine. In some examples, however, the trustedentity performs operations 1724-1728. In such examples, the assurancefrom the trusted entity is the key to establishing the date for thefirst document. This is because anyone can independently identify (withcertainty) a no-later-than date for the first blockchain record.However, only the trusted entity can hash the first document, if thedocument quarantine access is so limited. Therefore, operation 1730includes receiving, from the trusted entity, assurance that the firstblockchain record matches the first document. This assurance completesthe proof for date and integrity.

FIG. 18 illustrates the use of a network message for timestamping ablock. A digital item 1810, for example an electronic document such asan image, a video or audio recording, a word processing document, aspreadsheet, a presentation, a token or cryptocurrency transaction, atoken or cryptocurrency ledger, or any other digital file, is to beregistered in blockchain 100. Item 1810 is sent to an intake 1812 (e.g.,a node operated by permissioning entity or some other node or device),that uses a record generator 1808 to generate a rapid record 1804 a foritem 1810. As illustrated, rapid record 1804 a includes a first hashvalue 1820 for item 1810, a second hash value 1822 for item 1810, and anindex 1824, such as the count of rapid records having been generatedsince some reference time or event (e.g., on a particular date). Intake1812 also submits item 1810 to document corral 1300. A record for item1810, and other items within document corral 1300, will appear withinblockchain 100 as described in relation to FIG. 13 .

In some examples, hash values 1820 and 1822 include one or more portionsof the SHA-1, SHA-224, SHA-256, SHA-384, and the SHA-512 messagedigests. The use of two different hash values significantly increasesresistance to second preimage attacks. Together hash values 1820 and1822 form an IVC for item 1810. In some examples, rapid record 1804 awill appear as a short message service (SMS) message. A single SMSmessage has a character limit of around 160 characters, unless multiplemessages are strung together. A single SMS is able to hold SHA-1 andSHA-384, and still have 24 characters remaining for index 1824 and otherdata. A 4-character hexadecimal index field can indicate up to 65,535,which is sufficient to issue a new record index number every minute foran entire week, prior to resetting. A 3-character index field issufficient to issue a new record index number every minute for an entireday, and leaves more than 20 characters for other administrative data orcodes, such as versioning numbers. In some examples, rapid record 1804 ais also submitted to document corral 1300.

Rapid record 1804 a is entered into a rapid block 1802 a, which may alsobe submitted to document corral 1300. As illustrated, rapid block 1802 aholds rapid record 1804 a, subsequent rapid records 1804 b and 1804 c,and a rapid record 1804Z for a prior rapid block, thereby chaining rapidblock 1802 a and the prior rapid block. A network message generator 1818generates a network message 1806 a, and includes an IVC generator togenerate hash value 1830 and hash value 1832 for inclusion withinnetwork message 1806 a. In some examples, network message 1806 acomprises an SMS message. In some examples, network message 1806 acomprises a social media post, such as on Twitter or another socialmedia network. Some examples use network messages that are derived fromrapid blocks (as just described), some examples use network messagesthat are copies or near copies of rapid records, and some examples useboth. In either case, network message 1806 a indicates rapid record 1804a. Network message 1806 a also includes an index 1834.

Network message 1806 a is submitted to a public messaging network 1840for broadcasting. Network message 1806 a may also be submitted todocument corral 1300, whether by messaging network 1840 or anotherentity that generated network message 1806 a for submission to messagingnetwork 1840. Messaging network 1840 timestamps network message 1806 aand broadcasts network message 1806 a over public network 1846, whichmay be a wireless or wired network. For example, public network 1846 maybe a cellular network, a widely-distributed e-mail, or a website on theinternet. As illustrated, messaging network 1840 stores network message1806 a and other network messages 1806 b-1806 d in its storage 1842, forat least a while. Timestamps 1844 holds timestamping information fornetwork messages 1806 a-1806 d.

A monitoring node 1850, for example a third party that is unrelated toitem 1810, has no knowledge of the contents of item 1810, and thus hasno interest in falsifying data with regards to item 1810 monitors publicnetwork 1846 with a monitoring component 1856. Monitoring component 1856is able to receive broadcasts from public network 1846. As illustrated,monitoring node 1850 stores received network message 1806 a and otherreceived network messages 1806 b-1806 d that had been broadcast bymessaging network 1840, in its storage 1852. In some examples,monitoring node 1850 timestamps network messages 1806 a-1806 d as theyare received, and stores them in timestamps 1854. Timestamps 1854 mayprovide an independent time verification source for network messages1806 a-1806 d, that are outside the control of messaging network 1840.As shown, any of network messages 1806 a-1806 d, timestamps 1844, andtimestamps 1854 may be submitted to document corral for inclusion inblockchain 100.

Although messaging network 1840 may eventually delete network messages1806 a-1806 d and timestamps 1844, and monitoring node 1850 may ceaseoperations, thereby losing network messages 1806 a-1806 d timestamps1854, public records 112 a-112 d provide permanent, truly independentdate proof for copies of network messages 1806 a-1806 d within documentcorral 1300. Although public records 112 a-112 d do not have the finetime resolution of timestamps 1844 and 1854, they are independentlyverifiable and permanent.

FIG. 19 illustrates a timeline 1910 of using network messages fortimestamping blocks. A rapid parallel blockchain 1900 runs in parallelwith blockchain 100, but has a finer time resolution, for example aresolution on the order of a minute or an hour. In some examples,permissioning entity 101 may also manage blockchain 1900. Althoughblockchain 1900 has a finer time resolution than blockchain 100, and sothus may provide greater value in the context of tracking cryptocurrencytransactions or critical event timing for digital evidence, blockchain1900 provides only inherent ordinal timing proof and, for some timeresolutions, cannot match the time resolution with a printed publicrecord (e.g., a printed publication, such as a newspaper ad). Cardinaltiming proof may, in some examples, be provided externally by anotherentity, such as a cellular network carrier that stores SMS withtimestamps, such as timestamps 1844 of FIG. 18 . Such timing data, beingin the control of an entity that may have no interest in facilitatingthe operation or value of blockchain 1900, may eventually disappear. Andfurther, it is not truly independently verifiable, as anyone challengingthe timing of a record within blockchain 1900 must trust the accuracy ofthe timestamps—which may require trusting the entity generating andstoring the timestamps (e.g., messaging network 1840 of FIG. 18 ).Fortunately, however, the cardinal timing of the contents of blockchain1900 are independently verifiable using blockchain 100, although at thecoarser time resolution of blockchain 100.

In some scenarios, as time lapses, the need for finer time resolutionlessens. Consider, for example, cryptocurrency transactions. If acryptocurrency holder is attempting to spend a particular cryptocurrencyunit that was received only a matter of hours prior, blockchain 1900 maybe able to establish that the cryptocurrency holder is the proper owner.However, the transaction in which the cryptocurrency holder received theparticular cryptocurrency unit may not yet be established by blockchain100. In this scenario, the potential recipient, such as a retailer thataccepts the cryptocurrency, does not trust blockchain 1900, because theretailer does not trust timestamps created by a messaging networkoperator. However, the potential recipient does trust blockchain 100,because blockchain 100 is independently verifiable. When sufficient timehas passed that blockchain 100 can verify the transaction (in which thecryptocurrency holder received the particular cryptocurrency unit), thecryptocurrency holder will be able to spend the cryptocurrency unit withpotential recipients that only trust blockchain 100 but not blockchain1900.

In some examples, rapid parallel blockchain 1900 issues new blocks onthe order of a minute, using SMS messages 1806 a-1806 f fortimestamping. Although such timestamps (e.g., timestamps 1844) have afiner resolution than the intervals between public records 112 a, 112 b,and 112 c, the timestamps are under the control of messaging network1840. This means that, to at least some extent, messaging network 1840must be trusted to timestamp network messages accurately. For long termstorage, when messaging network 1840 no longer has any interest inmaintaining timestamp data and copies of network messages, thereliability of the timestamps may be determined by the reliability ofthe entity controlling the long term storage of the messages.

This is where the inclusion of the blocks 1802 a-1802 f of rapidparallel blockchain 1900 within blockchain 100 provides value (and alsoincluding network messages 1806 a-1806 f within blockchain 100). In thelong term, it can be established that the initially-applied timestamps(by messaging network 1840) had not been altered. Even if messagingnetwork 1840 ceases operations and all of its records are lost.Blockchain 100 may run at a rate in which new blocks are generatedhourly, daily, at set intervals each day, or some other interval (whichmay vary). For example, blocks for blockchain 100 may be generated at 9am, noon, and 5 pm in selected time zones, such as one or more ofCoordinated Universal Time (UTC), Eastern US, Pacific US, Japan StandardTime, and others. In some examples, blocks for blockchain 100 may begenerated at different time intervals on weekends and holidays.Although, in some examples, publication intervals for public records 112a, 112 b, and 112 c (of FIGS. 1A and 18 ) may be daily or slower, ifblocks for blockchain 100 are generated at a more rapid rate, multipleIVCs for the multiple closed blocks closed (during each publicationinterval) may be published in each of public records 112 a, 112 b, and112 c. For example, public record 112 a may have nine advertisementsrepresenting three block closing times (9 am, noon, and 5 pm) in each ofthree time zones.

In operation, records 1804 a-1804 d arrive during a time window 1904 a,and are included in block 1802 a. Block 1802 a becomes part ofblockchain 1900. Network message 1806 a is generated from block 1802 afor broadcast, and is timestamped. Record 1804 e is generated for block1802 a during a next time window 1904 b. Additional records 1804 f and1804 g arrive during time window 1904 b. Records 1804 e-1804 g areincluded in block 1802 b. Record 1804 e chains blocks 1802 a and 1802 b,and block 1802 b becomes part of blockchain 1900. Network message 1806 bis generated from block 1802 b for broadcast, and is timestamped. Record1804 h is generated for block 1802 b during a next time window 1904 c.Additional records 1804 i and 1804J arrive during time window 1904 c.Records 1804 h-1804J are included in block 1802 c. Record 1804 h chainsblocks 1802 b and 1802 c, and block 1802 c becomes part of blockchain1900. Network message 1806 c is generated from block 1802 c forbroadcast, and is timestamped. Record 1804 k is generated for block 1802c during a next time window 1904 d. Additional records 1804L and 1804 marrive during time window 1904 d.

Records 1804 k-1804 m are included in block 1802 d. Record 1804 k chainsblocks 1802 c and 1802 d, and block 1802 d becomes part of blockchain1900. Network message 1806 d is generated from block 1802 d forbroadcast, and is timestamped. Record 1804 n is generated for block 1802d during a next time window 1904 e. No additional records arrive duringtime window 1904 e, so only records 1804 n is included in block 1802 e.Record 1804 n chains blocks 1802 d and 1802 e, and block 1802 e becomespart of blockchain 1900. Network message 1806 e is generated from block1802 e for broadcast, and is timestamped. Record 1804 o is generated forblock 1802 e during a next time window 1904 f. Additional records 1804p, 1804 q, and 1804 r arrive during time window 1904 c. Records 1804o-1804 r are included in block 1802 f. Record 1804 o chains blocks 1802e and 1802 f, and block 1802 f becomes part of blockchain 1900. Networkmessage 1806 f is generated from block 1802 f for broadcast, and istimestamped. Record 1804 s is generated for block 1802 d during a nexttime window, and this process repeats. Blocks 1802 a-1802 f and possiblyalso network messages 1806 a-1806 f are put into blockchain 100. Asillustrated, time windows 1904 a-1904 c are portions of time window 1902a, so blocks 1802 a-1802 c of blockchain 1900 become part of block 102 aof blockchain 100. Time windows 1904 d-1904 f are portions of timewindow 1902 b, so blocks 1802 d-1802 f of blockchain 1900 become part ofblock 102 b of blockchain 100. In some examples, the ratio of the numberof time windows for blocks of blockchain 1900 to the number of timewindows for blocks of blockchain 100 are significantly different, suchas on the order of hundreds or even thousands.

FIG. 20 illustrates the use of a digital evidence bag (DEB) withblockchain 100, and optionally rapid parallel blockchain 1900. Evidenceis collected digitally from a scene 2002 using sensor 2004 a and sensor2004 b of an evidence collection device 2006. In some examples, sensors2004 a and 2004 b comprise a camera and a microphone, respectively,although a different set and number of sensors may be used. Evidencecollection device 2006 has a local evidence store 2008 that holdsevidence item 1810 a and evidence item 1810 b, collected from scene2002. In some examples, evidence collection device 2006 is an instanceof intake 1812 (of FIG. 18 ). In some examples, a network messagegenerator 1818 on evidence collection device 2006 generates a networkmessage 1806 g and a network message 1806 h. In some examples, networkmessages 1806 g and 1806 h comprise SMS messages.

Evidence collection device 2006 sends evidence items 1810 a and 1810 bto a DEB operator 2010 over a network 2522. DEB operator 2010 has alocal evidence store 2012 that holds evidence items 1810 a and 1810 bfrom evidence collection device 2006, and also evidence item 1810 c frompotentially another source. DEB operator 2010 has a rapid blockgenerator 2014 that generates a rapid block for all evidence itemscollected within a prior time period, such as the prior two minutes. Forexample, a record may be generated for each of evidence items 1810a-1810 c, and placed into a block 1802 i. In some examples, DEB operator2010 has a network message generator 1818 that generates network message1806 i (for example, an SMS) indicating block 1802 i, for example usingthe processes described in relation to FIG. 18 .

Messaging network 1840 receives network messages 1806 g-1806 i forbroadcast (e.g., over public network 1846), timestamps them, and storestheir timestamps in timestamps 1844. Messaging network 1840 may receivenetwork messages from any of evidence collection device 2006, DEBoperator 2010, and even permissioning entity 101. Document corral hascopies of evidence items 1810 a-1810 c, network messages 1806 g-1806 i,and block 1802 i. Document corral may receive various ones of these fromany of evidence collection device 2006, DEB operator 2010, and messagingnetwork 1840. When a subsequent block 1802J is chained to block 1802 iby holding a record 1804 u that includes an IVC for block 1802 i, aportion of blockchain 1900 is formed. In some examples, DEB operator2010 and/or permissioning entity 101 may manage blockchain 1900.Blockchain 1900 provides time and integrity proof for at least evidenceitems 1810 a and 1810 because IVCs (hash values) for evidence items 1810a and 1810 are contained within block 1802 i. Blockchain 100 alsoprovides integrity proof for at least evidence items 1810 a and 1810because the contents of blockchain 1900 are within blockchain 100. Thedate resolution for blockchain 100 is coarser, on the order of days,rather than a minute or so.

FIG. 21 illustrates a flowchart 2100 of operations associated with usingnetwork messages for timestamping a block in blockchain 100. In someexamples, at least a portion of flowchart 2100 is performed using one ormore computing devices 2500. Operation 2102 includes receiving an itemat an intake. In some examples, the first item is an electronicdocument. In some examples, the electronic document comprises at leastone item selected from the list consisting of an image, an audiorecording, a video recording, and a word processing document. In someexamples, the intake comprises an evidence collection device comprisinga sensor. In some examples, the sensor comprises at least one sensorselected from the list consisting of a camera, an infrared image sensor,and RF sensor, a microphone, and an ultrasonic sensor. In some examples,the evidence collection device includes a local evidence storecontaining the received tem as an evidence item. In some examples, theevidence collection device submits the evidence item to a DEB operator,and receiving an item at an intake comprises the DEB operator receivingthe evidence item from the evidence collection device.

Operation 2104 includes generating a first rapid record, the first rapidrecord comprising an IVC for the item. Thus, operation 2104 includesgenerating the IVC. In some examples, the IVC comprises a hash valuecomprising a complete message digest. In some examples, the IVCcomprises a hash value comprising a partial message digest. In someexamples, the IVC comprises a hash value comprising two message digests.In some examples, the IVC comprises a mixture of partial and completemessage digests. In some examples, the hash value includes one or moreportions of the SHA-1, SHA-224, SHA-256, SHA-384, and the SHA-512message digests. In some examples, the first rapid record comprises anindex value. At this point it is optional to add the first rapid recordto a document corral for inclusion in a date-provable blockchain.Operation 2106 includes entering the first rapid record into thedocument corral. In some examples, operation 2106 includes submittingthe evidence item to a document corral by the evidence collection deviceand/or the DEB operator.

Operation 2108 includes generating a first rapid block comprising thefirst rapid record and a second rapid record. In some examples, thefirst rapid block comprises an index value. In some examples, the firstrapid block comprises an IVC (hash value, message digest) for a priorrapid block, thereby chaining the first rapid block and the prior rapidblock. Operation 2110 includes generating an IVC for the first rapidblock. At this point it is optional to add the first rapid block to thedocument corral, so operation 2106 includes entering the first rapidblock into the document corral. Operation 2112 includes generating anetwork message indicating the first rapid record. In some examples, thenetwork message indicating the first rapid record comprises at least aportion of the first rapid record. In some examples, the network messageindicating the first rapid record comprises at least the IVC of thefirst rapid block. In some examples, the network message comprises anSMS message or a social media post. In some examples, the evidencecollection device generates a network message indicating the evidenceitem. In some examples, the DEB operator generates the network messageindicating the evidence item.

Operation 2114 includes submitting the network message indicating thefirst rapid record to a public messaging network for broadcasting. Insome examples, the evidence collection device submits the networkmessage indicating the evidence item to a public messaging network forbroadcasting. In some examples, the DEB operator submits the networkmessage indicating the evidence item to the public messaging network forbroadcasting. Operation 2116 includes timestamping, by the publicmessaging network, the network message indicating the first rapidrecord. At this point it is optional to add a copy of the networkmessage to the document corral, so operation 2106 includes entering acopy of the network message into the document corral. In some examples,operation 2106 also includes entering the timestamp of the networkmessage into the document corral. Operation 2118 includes broadcasting,by the public messaging network, the network message indicating thefirst rapid record over a public medium. In some examples, broadcastingincludes sending the network message over a wired network and/or awireless network to paid subscribers.

Operation 2120 includes receiving the broadcast network message at amonitoring node. In some examples the monitoring node is also a DEBoperator. Operation 2122 includes timestamping the received broadcastnetwork message. At this point it is optional to add a copy of thereceived broadcast network message to the document corral, so operation2106 includes entering the received broadcast network message into adocument corral. In some examples, operation 2106 also includes enteringthe timestamp of the received broadcast network message into thedocument corral.

Operation 2124 includes generating a rapid blockchain comprising theprior rapid block, the prior rapid block, and a subsequent rapid block.In some examples, the subsequent rapid block comprises an IVC (hashvalue, message digest) for the first rapid block, thereby chaining thesubsequent rapid record and the first rapid block. In some examples,blocks of the rapid blockchain are generated at time intervals of twominutes or less. In some examples, blocks of the rapid blockchain aregenerated at time intervals of an hour or less. Although the rapidblockchain uses timestamps provided by the public messaging network,which may not be a trusted timestamping entity (TTE), the rapidblockchain does provide higher time resolution than the slowerblockchain which does have provable dates. Fortunately, the slowerblockchain provides a provable date, although with coarser timeresolution. Operation 2126 includes generating a blockchain recordindicating the first rapid record. In some examples, the blockchainrecord indicating the first rapid record comprises the first rapidrecord. In some examples, the blockchain record indicating the firstrapid record comprises the first rapid block. In some examples, theblockchain record indicates the first rapid record comprises a timestampfor the first rapid block. In some examples, operation 2126 is part of alarger operation that includes generating blockchain records for thefirst blockchain from entries in the document corral.

The first blockchain record is added into the slower blockchain, usingone or more of flowcharts 900, 1000, 1400, and 1700. In some examples, ablock of the first blockchain comprises multiple blocks of the rapidblockchain. In some examples, blocks of the first blockchain aregenerated at time intervals of an hour or less. In some examples, blocksof the first blockchain are generated at time intervals of a day orless. In some examples, blocks of the first blockchain are generatedaccording to a schedule at a set of selected times in a set of selectedtime zones. In some examples, the schedule varies according to holiday.For later proving the date and integrity of the item received inoperation 2102, operation 2128 includes retrieving a timestamp from thepublic messaging network, such as a timestamp generated in operation2116 and/or operation 2122. Flowchart 1200 completes the proof, with theretrieved timestamp providing finer time resolution.

FIG. 22 illustrates an arrangement of data for a self-addressedblockchain registration (SABRe). A user at a user node 2208 intends toregister a document 2208 a in blockchain 100, and so makes a reservationrequest 2210 requesting a reserved blockchain address. In some examples,reservation request 2210 includes a specific date and a specific time.In some examples, reservation request 2210 indicates a time period, suchas no-earlier-than and no later-than dates. Permissioning entity 101receives reservation request 2210 and uses reservation data 2220 todetermine a reserved blockchain address 2212. Reserved blockchainaddress 2212 may include an identified block number and may also includean index number within that identified block, similarly to blockchainaddress 518 (of FIG. 5 ). That is, in some examples, reserved blockchainaddress 2212 includes both a block ID and an index value. For example,permissioning entity 101 maintains a schedule 2222 for generatingupcoming blocks, identifies one or more blocks matching the requesteddate, selects a block, and enters reserved blockchain address 2212 intoa list of reservations 2224.

Upon receiving reserved blockchain address 2212, the user enters it (ora suitable indication) into document 2208 a to make it into document2208 b. The user generates a blockchain record 2204 for document 2202 b.Document 2202 b now is able to indicate its own blockchain registration,and when hashed at a later time (e.g., during verification in order toresolve a dispute), will reproduce the hash value (IVC) within therecord that it indicates internally. This capability is not currentlyachievable with any other blockchain, other than PEDDaL®.

User node 2208 generates a message 2206 including record 2204 andreserved blockchain address 2212 and transmits message 2206 topermissioning entity 101. Permissioning entity 101 receives message 2206that associates record 2204 with reserved blockchain address 2212.Permissioning entity 101 identifies reserved blockchain address 2212within reservations 2224 and uses a record scheduler 2228 to schedulinginclusion of record 2204 in blockchain 100 according to reservedblockchain address 2212. If record 2204 is not received in time, butreserved blockchain address 2212 had included a reserved index value,permissioning entity may zero pad the location within the scheduledblock that corresponds to the reserved index (or just put in a differentrecord at that location).

Record 2204 is placed into a record storage 2226 to await its scheduledblock. If record 2204 is received early enough prior to the generationof the scheduled block, permissioning entity 101 may also include record2204 in an earlier block as an early record. A linking component 2232generates a linked record locating field (e.g., record locator field 502p) with reserved blockchain address 2212, to turn record 2204 intorecord 2204 a. A block assembly component 2230 puts records into blocksfor blockchain 100, including record 2204 a. Upon the generation periodfor the scheduled block, if an early record had appeared in an earlierblock, linking component 2232 generates a linked record locating fieldwith the blockchain address of that earlier record (record 2204 a), toturn record 2204 into record 2204 b. Block assembly component 2230 putsrecord 2204 b (or record 2204, if there is no linking information) intoblockchain 100 as scheduled (possibly also at the scheduled indexposition).

FIG. 23 illustrates additional detail an arrangement of data for aSABRe-enabled blockchain. Document 2202 b has a document content section2302 and a SABRe reference section 2304. SABRe reference section 2304includes an indication of a reserved blockchain address 2212. In someexamples, reserved blockchain address 2212 includes both a block numberand an index value, such as the number of block 102 d and the value ofindex 2308. In some examples, reserved blockchain address 2212 does notinclude an index value.

IVC generator 108 generates a hash value 2306 for document 2202 b. Arecord generator (not shown) includes IVC generator 108 and places hashvalue 2306 (or another IVC, as generated by IVC generator 108) withinscheduled record 2204 b. As illustrated, early record 2204 a has thesame hash value 2306. This is because early record 2204 a and scheduledrecord 2204 b are both for the same document 2202 b. As illustrated,early record 2204 a, has a linked record value in a linked record field2320 that indicating a blockchain address (e.g., the number of block 102d and the value of index 2308) of scheduled record 2204 b. Also asillustrated, scheduled record 2204 b, has a linked record value in alinked record field 2310 that indicating a blockchain address (e.g., thenumber of block 102 b and the value of index 2328) of early record 2204a.

Anyone possessing a copy of document 2202 b can locate scheduled record2204 b using the indication of reserved blockchain address 2212 indocument 2202 b. This permits determining integrity or a no-later-thandate of existence for document 2202 b using scheduled record 2204 b.However with linked records, finding scheduled record 2204 b enableslocating early record 2204 a using the linked record value (withinscheduled record 2204 b) for early record 2204 a. This permitsdetermining integrity or a no-later-than date of existence for document2202 b using early record 2204 a. In some scenarios, this earlierprovable date may be valuable.

In some examples, the SABRe reference section 2304 is printed in afooter of a document, so that the blockchain registration is easilylocated by anyone who sees any copy of the document. Such examples thusinclude printing a blockchain address (blockchain registration address)of a blockchain record (for the document) on a copy of the documentitself. This may be performed in combination with use of a daisy chainedrecord, a document corral, a quarantine-enabled document corral, anetwork message for timestamping, a rapid parallel blockchain, a DEB,and/or other examples described herein.

A real-world example exists for the PEDDaL® blockchain. The text shownin document content section 2302 and SABRe reference section 2304 are inan ASCII text file (so no metadata or other extraneous word processingfile data to throw off the hash values), with a single space between“experience.” and “The PEDDaL”, and a single carriage return between“mechanism.” and “This document”. After “at:” there is a single space,followed by “191205 a0000A5” in lieu of the text window placeholder forreserved blockchain address 2212. There are no other spaces or carriagereturns, and text file has 319 bytes (characters). The text documentpredicts its own blockchain registration, because hashing the text fileproduces the SHA-512 and SHA-1 message digests found in the record atindex value 0xA5 in block 191205 a. By recreating the above-describedtext file carefully, this self-referencing blockchain registration canbe independently verified.

FIG. 24 illustrates a flowchart 2400 of operations associated with usinga SABRe-enabled version of blockchain 100. In some examples, at least aportion of flowchart 2400 is performed using one or more computingdevices 2500. In some examples, the operations described for flowchart2400 coincide with (or may be replaced by) similar operations describedfor flowcharts 900, 1000, 1100, 1200, 1400, and/or 1700. As indicated,some operations of flowchart 2400 are performed by a user (or set ofpeople submitting a scheduled record) or a third party performingverification, whereas some are performed by the permissioning entitythat produces the blockchain.

Operation 2402 includes requesting a reserved blockchain address.Operation 2404 includes receiving the request to reserve a blockchainaddress. Operation 2406 includes determining a reserved blockchainaddress. Operation 2408 includes returning the reserved blockchainaddress. In some examples, the reserved blockchain address includes botha block ID and an index value. Operation 2410 includes receiving thereserved blockchain address. In some examples, the reserved blockchainaddress includes both a block ID and an index value.

Now that the document owner has the reserved blockchain address,operation 2412 includes entering an indication of the reservedblockchain address into a document. Operation 2414 includes generating arecord for the document. In some examples, generating a record for thedocument comprises generating a record for a document containing anindication of the reserved blockchain address. Operation 2416 includestransmitting the record for the document with an association of thereserved blockchain address to the permissioning entity, (or some othernode that collects records). Operation 2418 includes the permissioningentity receiving a record associated with the reserved blockchainaddress. Operation 2420 includes scheduling inclusion of the receivedrecord in the blockchain according to the reserved blockchain address.

If the record is received while another block is being generated, beforethe scheduled block, the permissioning entity may also include therecord in the earlier block as an early record. The permissioning entitymay also put a linked record within the early record for the scheduledrecord, since the schedule is already known via the reservations. Thus,optional operation 2422 includes including, within an early record, alinked record value indicating a blockchain address of the scheduledrecord, and operation 2424 includes additionally including the receivedrecord, as an early record, in the blockchain in an earlier block, priorto the schedule. Operation 2426 includes including, within the scheduledrecord, a linked record value indicating a blockchain address of theearly record. Operation 2428 includes including the received record, asa scheduled record, in the blockchain according to the schedule.Operation 2430 includes distributing copies of the blockchain outsidethe control of a permissioning entity of the blockchain, such that thepermissioning entity is unable to alter the blockchain withoutdetection. In some examples, distributing copies of the blockchainoutside the control of a permissioning entity of the blockchaincomprises publishing the blockchain on a website.

At a later time, when the document requires date and/or integrityverification, operation 2432 includes locating the scheduled recordwithin the blockchain using the indication of the reserved blockchainaddress in the document. If somehow, the early record had already beenlocated, it is also possible to identify, within a linked record locatorfield of the early record, a linked record value for the scheduledrecord. This then permits locating the scheduled record within theblockchain using the linked record value for the scheduled record.Operation 2434 includes determining integrity or a no-later-than date ofexistence for the document using the scheduled record in the blockchain.In some examples, determining integrity for a document comprisesgenerating an IVC for the document and comparing the generated IVC forthe document with a recorded IVC within a record within the blockchain.In some examples, determining a no-later-than date of existence for adocument comprises hashing the document, comparing a resulting hashvalue with a recorded hash value within the blockchain. In someexamples, determining a no-later-than date of existence for a block ofthe blockchain that contains the recorded hash value.

Since the address of the scheduled record is identified within thedocument, is may be easier to initially locate the scheduled record.However, if an early record had also been generated and linked, it ispossible to locate the early record using the scheduled record. Thus,operation 2436 includes identifying, within a linked record locatorfield of the scheduled record, a linked record value for the earlyrecord. Operation 2438 includes locating the early record within theblockchain using the linked record value for the early record. Operation2440 includes determining integrity or a no-later-than date of existencefor the document using the early record in the blockchain.

Some aspects and examples disclosed herein are directed to a method ofusing a first blockchain to generate evidence for proving documentintegrity, the method executable by a processor, the method comprising:generating, for a document, a first record in a first format, the firstformat comprising: an IVC field comprising a first IVC portion; an indexfield; and a linked record locator field; wherein the first recordcomprises: a first IVC value in the first IVC portion of the firstrecord; a first index value in the index field of the first record; anda first linked record value in the first linked record locator field ofthe first record; and generating, in the first blockchain, a first blockcomprising the first record, wherein the first linked record valueindicates a location of a second record in the first blockchain.

Alternatively, or in addition to the other examples described herein,examples include any combination of the following:

-   -   the first linked record value comprises a blockchain address for        another record;    -   the IVC field further comprises a second IVC portion, the record        further comprises a second IVC value in the second IVC portion,        the second IVC value represents a same document as the first IVC        value, and the second IVC value represents an output of a        different integrity verification function than the first IVC        value;    -   the first IVC value comprises at least a portion of a SHA value;    -   the first IVC value comprises at least a portion of a hash value        (message digest of a hash function);    -   the SHA is at least one selected from the list consisting of:        SHA-1, SHA-224, SHA-256, SHA-348, and SHA-512;    -   the first format further comprises a timestamp field, and the        first record further comprises a timestamp value in the        timestamp field;    -   the first format further comprises a generator version field,        and the first record further comprises generator version        information in the generator version field;    -   the first format has a fixed number of bytes;    -   the first format is 256 bytes long;    -   the location of the second record is within the first block;    -   the second record is in the first format and the second record        comprises: a second IVC value in the first IVC portion of the        second record; and a second index value in the index field of        the second record;    -   the second record further comprises: the first index value in        the first linked record locator field of the second record;    -   the second record further comprises: a third index value in the        first linked record locator field of the second record;    -   the second record further comprises: a block name in the first        linked record locator field of the second record;    -   the location of the second record is within a second blockchain;    -   the location of the second record is within a first prior block        that is prior to the first block in the first blockchain;    -   the second record comprises a location of a third record,        thereby linking the first record with the third record in a        daisy chain;    -   the location of the third record is within a second prior block        that is prior to the first prior block in the first blockchain;        and    -   printing a blockchain address of a blockchain record on a copy        of the document.

Some aspects and examples disclosed herein are directed to a method ofusing a blockchain to generate evidence for proving document integrity,the method executable by a processor, the method comprising: providing adocument corral; based at least on permissions set for externalentities, granting external entities access to the document corral;monitoring documents within the document corral for additions andalterations; based at least upon detecting an addition or alteration ofa first document within the document corral, generating a blockchainrecord for the first document; and adding the blockchain record into theblockchain.

Alternatively, or in addition to the other examples described herein,examples include any combination of the following:

-   -   generating the blockchain;    -   receiving new documents into the document corral;    -   altering documents within the document corral;    -   generating a blockchain record for the first document includes        generating a blockchain record with a linked record value;    -   the linked record value indicates a prior version of the first        document;    -   the linked record value indicates a second document that is        related to the first document;    -   the linked record value comprises a blockchain address;    -   a relationship of the second document with the first document is        established by the first document and the second document being        attached to a common electronic message;    -   generating the block upon a trigger event;    -   the trigger event comprises a schedule or a threshold number of        new records awaiting entry into the blockchain;    -   distributing copies of the blockchain outside the control of a        permissioning entity of the blockchain, such that the        permissioning entity is unable to alter the blockchain without        detection;    -   distributing copies of the blockchain outside the control of a        permissioning entity of the blockchain comprises publishing the        blockchain on a website;    -   retrieving documents from the document corral;    -   ensuring that a set of retrieved documents is complete;    -   ensuring that a set of retrieved documents is complete comprises        traversing linked record locator fields to rebuild a daisy chain        of document relationships;    -   based at least on determining that documents are missing,        generating an alert; and    -   printing a blockchain address of a blockchain record on a copy        of the document.

Some aspects and examples disclosed herein are directed to a method ofusing a blockchain to generate evidence for proving document integrity,the method executable by a processor, the method comprising: providing adocument corral and a document quarantine; generating a first blockchainrecord for a first document; adding the first blockchain record into theblockchain; identifying that the first document is to be quarantined;based at least upon determining that the first document is to bequarantined, moving the first document into the document quarantine;generating a second document as a replacement for the first document inthe document corral, the second document not triggering quarantine;generating a second blockchain record for the second document; andadding the second blockchain record into the blockchain.

Alternatively, or in addition to the other examples described herein,examples include any combination of the following:

-   -   generating the blockchain;    -   entering the first blockchain record into the blockchain;    -   monitoring documents within the document corral for quarantine        triggers;    -   quarantine triggers are selected from the list consisting of:        privacy violations, intellectual property rights violations,        malicious logic, and obscenity;    -   removing the first document from the document corral;    -   generating the second document from the first document by        removing material that triggered quarantine;    -   generating the second document as a summary of the first        document;    -   generating a cleaned reference document;    -   the cleaned reference document includes at least one item        selected from the list consisting of: identification of the        first document, identification of a quarantine location of the        first document, a blockchain address of the first record,        identification of the second document, a blockchain address of        the second record;    -   generating a second blockchain record for the second document        includes generating a blockchain record with a linked record        value;    -   the linked record value indicates a blockchain address of the        first record;    -   the linked record value indicates the first document;    -   the linked record value indicates quarantine storage;    -   distributing copies of the blockchain outside the control of a        permissioning entity of the blockchain, such that the        permissioning entity is unable to alter the blockchain without        detection;    -   distributing copies of the blockchain outside the control of a        permissioning entity of the blockchain comprises publishing the        blockchain on a website;    -   retrieving the second document from the document corral;    -   determining integrity or a no-later-than date of existence for        the second document using the blockchain;    -   determining integrity for a document using the blockchain        comprises generating an IVC for the document and comparing the        generated IVC for the document with a recorded IVC within a        record within the blockchain;    -   determining a no-later-than date of existence for a document        using the blockchain comprises hashing the document; comparing a        resulting hash value with a recorded hash value within the        blockchain; and determining a no-later-than date of existence        for an earliest block of the blockchain that contains the        recorded hash value;    -   determining a no-later-than date of existence for a document        using the blockchain comprises generating an IVC for the        document; comparing the generated IVC for the document with a        recorded IVC within a record within the blockchain; and        determining a no-later-than date of existence for an earliest        block of the blockchain that contains the recorded IVC;    -   identifying, within a linked record locator field of the second        blockchain record, a linked record value for the first        blockchain record;    -   identifying, within a linked record locator field of the second        blockchain record, a linked record value for the first document;    -   locating the first blockchain record within the blockchain;    -   determining a no-later-than date of existence for the first        document using the blockchain and the first blockchain record;    -   receiving, from a trusted entity, assurance that the first        blockchain record matches the first document;    -   retrieving the first document from the document quarantine;    -   determining integrity or a no-later-than date of existence for        the first document using the blockchain; and    -   printing a blockchain address of a blockchain record on a copy        of the document.

Some aspects and examples disclosed herein are directed to a method ofusing a blockchain to generate evidence for proving document integrity,the method executable by a processor, the method comprising: receivingan item at an intake; generating a first rapid record, the first rapidrecord comprising an IVC for the item; generating a network messageindicating the first rapid record; submitting the network messageindicating the first rapid record to a public messaging network forbroadcasting; generating a blockchain record indicating the first rapidrecord; and adding the blockchain record into a first blockchain.

Alternatively, or in addition to the other examples described herein,examples include any combination of the following:

-   -   the first item is an electronic document;    -   the electronic document comprises at least one item selected        from the list consisting of: an image, an audio recording, a        video recording, and a word processing document;    -   the IVC comprises a hash value comprising a complete message        digest;    -   the IVC comprises a hash value comprising a partial message        digest;    -   the IVC comprises a hash value comprising two message digests;    -   the IVC comprises a mixture of partial and complete message        digests;    -   the hash value includes one or more portions of the SHA-1,        SHA-224, SHA-256, SHA-384, and the SHA-512 message digests;    -   the first rapid record comprises an index value;    -   entering the first rapid record into a document corral;    -   the blockchain record indicates the first rapid record comprises        the first rapid record;    -   the network message indicates the first rapid record comprises        at least a portion of the first rapid record;    -   generating a first rapid block comprising the first rapid record        and a second rapid record;    -   the first rapid block comprises an index value;    -   entering the first rapid block into a document corral;    -   the blockchain record indicates the first rapid record comprises        the first rapid block;    -   generating an IVC for the first rapid block;    -   the network message indicates the first rapid record comprises        at least the IVC of the first rapid block;    -   the first rapid block comprises an index value;    -   broadcasting, by the public messaging network, the network        message indicating the first rapid record over a public medium;    -   timestamping, by the public messaging network, the network        message indicating the first rapid record;    -   the network message comprises an SMS message or a social media        post;    -   broadcasting includes sending the network message over a wired        network and/or a wireless network to paid subscribers;    -   receiving the broadcast network message;    -   entering the received broadcast network message into a document        corral;    -   timestamping the received broadcast network message;    -   entering the timestamp of the received broadcast network message        into a document corral;    -   the blockchain record indicates the first rapid record comprises        a timestamp for the first rapid block;    -   the first rapid block comprises an IVC (hash value, message        digest) for a prior rapid block, thereby chaining the first        rapid block and the prior rapid block;    -   generating a rapid blockchain comprising the prior rapid block,        the prior rapid block, and a subsequent rapid block;    -   the subsequent rapid block comprises an IVC (hash value, message        digest) for the first rapid block, thereby chaining the        subsequent rapid record and the first rapid block;    -   a block of the first blockchain comprises multiple blocks of the        rapid blockchain;    -   blocks of the rapid blockchain are generated at time intervals        of two minutes or less;    -   blocks of the rapid blockchain are generated at time intervals        of an hour or less;    -   blocks of the first blockchain are generated at time intervals        of an hour or less;    -   blocks of the first blockchain are generated at time intervals        of a day or less;    -   blocks of the first blockchain are generated according to a        schedule at a set of selected times in a set of selected time        zones;    -   the schedule varies according to holidays;    -   the intake comprises an evidence collection device comprising a        sensor;    -   the sensor comprises at least one sensor selected from the list        consisting of a camera, an infrared image sensor, and RF sensor,        a microphone, and an ultrasonic sensor;    -   the evidence collection device includes a local evidence store        containing the received tem as an evidence item;    -   the evidence collection device generates a network message        indicating the evidence item;    -   the evidence collection device submits the network message        indicating the evidence item to a public messaging network for        broadcasting;    -   the evidence collection device submits the evidence item to a        DEB operator;    -   the DEB operator generates a network message indicating the        evidence item;    -   the DEB operator submits the network message indicating the        evidence item to a public messaging network for broadcasting;    -   submitting the evidence item to a document corral by the        evidence collection device and/or the DEB operator; and    -   generating blockchain records for the first blockchain from        entries in the document corral.

Some aspects and examples disclosed herein are directed to a method ofusing a blockchain to generate evidence for proving document integrity,the method executable by a processor, the method comprising: receiving arequest to reserve a blockchain address; returning a reserved blockchainaddress; receiving a record associated with the reserved blockchainaddress; scheduling inclusion of the received record in the blockchainaccording to the reserved blockchain address; and including the receivedrecord, as a scheduled record, in the blockchain according to theschedule.

Alternatively, or in addition to the other examples described herein,examples include any combination of the following:

-   -   the reserved blockchain address includes both a block ID and an        index value;    -   requesting the reserved blockchain address;    -   determining the reserved blockchain address;    -   entering an indication of the reserved blockchain address into a        document;    -   generating a record for a document;    -   generating a record for a document comprises generating a record        for a document containing an indication of the reserved        blockchain address;    -   transmitting the record for the document with an association of        the reserved blockchain address;    -   additionally including the received record, as an early record,        in the blockchain in an earlier block, prior to the schedule;    -   including, within the early record, a linked record value        indicating a blockchain address of the scheduled record;    -   including, within the scheduled record, a linked record value        indicating a blockchain address of the early record;    -   determining integrity or a no-later-than date of existence for        the document using the scheduled record in the blockchain;    -   determining integrity or a no-later-than date of existence for        the document using the early record in the blockchain;    -   identifying, within a linked record locator field of the        scheduled record, a linked record value for the early record;    -   locating the early record within the blockchain using the linked        record value for the early record;    -   identifying, within a linked record locator field of the early        record, a linked record value for the scheduled record;    -   locating the scheduled record within the blockchain using the        linked record value for the scheduled record;    -   locating the scheduled record within the blockchain using the        indication of the reserved blockchain address in the document;    -   determining integrity for a document comprises generating an IVC        for the document and comparing the generated IVC for the        document with a recorded IVC within a record within the        blockchain;    -   determining a no-later-than date of existence for a document        comprises hashing the document; comparing a resulting hash value        with a recorded hash value within the blockchain; and        determining a no-later-than date of existence for a block of the        blockchain that contains the recorded hash value;    -   distributing copies of the blockchain outside the control of a        permissioning entity of the blockchain, such that the        permissioning entity is unable to alter the blockchain without        detection; and    -   distributing copies of the blockchain outside the control of a        permissioning entity of the blockchain comprises publishing the        blockchain on a website.

Some aspects and examples disclosed herein are directed to a systemcomprising: a processor; and a computer-readable medium storinginstructions that are operative, upon execution by the processor, toperform operations disclosed herein. Some aspects and examples disclosedherein are directed to one or more computer storage devices havingcomputer-executable instructions stored thereon, which, on execution bya computer, cause the computer to perform operations disclosed herein.While the aspects of the disclosure have been described in terms ofvarious examples with their associated operations, a person skilled inthe art would appreciate that a combination of operations from anynumber of different examples is also within scope of the aspects of thedisclosure.

FIG. 25 is a block diagram of example computing device 2500 forimplementing aspects disclosed herein and is designated generally ascomputing device 2500. Computing device 2500 is one example of asuitable computing environment and is not intended to suggest anylimitation as to the scope of use or functionality of the examplesdisclosed herein. Neither should computing device 2500 be interpreted ashaving any dependency or requirement relating to any one or combinationof components/modules illustrated. The examples disclosed herein may bedescribed in the general context of computer code or machine-useableinstructions, including computer-executable instructions such as programcomponents, being executed by a computer or other machine, such as apersonal data assistant or other handheld device. Generally, programcomponents including routines, programs, objects, components, datastructures, and the like, refer to code that performs particular tasks,or implement particular abstract data types. The disclosed examples maybe practiced in a variety of system configurations, including personalcomputers, laptops, smart phones, mobile tablets, hand-held devices,consumer electronics, specialty computing devices, etc. The disclosedexamples may also be practiced in distributed computing environmentswhen tasks are performed by remote-processing devices that are linkedthrough a communications network.

Computing device 2500 includes a bus 2502 that directly or indirectlycouples the following devices: memory 2504, one or more processors 2506,one or more presentation components 2508, input/output (I/O) ports 2510,I/O components 2512, a power supply 2514, and a network component 2516.Computer device 2500 should not be interpreted as having any dependencyor requirement related to any single component or combination ofcomponents illustrated therein. While computer device 2500 is depictedas a seemingly single device, multiple computing devices 2500 may worktogether and share the depicted device resources. For instance,computer-storage memory 2504 may be distributed across multiple devices,processor(s) 2506 may provide housed on different devices, and so on.Bus 2502 represents what may be one or more busses (such as an addressbus, data bus, or a combination thereof). Although the various blocks ofFIG. 25 are shown with lines for the sake of clarity, example systemsmay be less delineated. Distinction is not made between such categoriesas “workstation,” “server,” “laptop,” “hand-held device,” etc., as allare contemplated within the scope of FIG. 25 and the references hereinto a “computing device.”

Computer-storage memory 2504 may take the form of the non-transitorycomputer-storage media referenced below and operatively provided storageof computer-readable instructions, data structures, program modules andother data for computing device 2500. For example, memory 2504 may storean operating system and other program modules and program data. Memory2504 may be used to store and access instructions configured to carryout the various operations disclosed herein and may includecomputer-storage media in the form of volatile and/or nonvolatilememory, removable or non-removable memory, data disks in virtualenvironments, or a combination thereof. Memory 2504 may include anyquantity of memory associated with or accessible by the computing device2500. Memory 2504 may be internal to the computing device 2500, externalto the computing device 2500, or both. Examples of memory 2504 include,without limitation, random access memory (RAM); read only memory (ROM);electronically erasable programmable read only memory (EEPROM); flashmemory or other memory technologies; CD-ROM, digital versatile disks(DVDs) or other optical or holographic media; magnetic cassettes,magnetic tape, magnetic disk storage or other magnetic storage devices;memory wired into an analog computing device; or any other medium forencoding desired information and for access by computing device 2500.Additionally, or alternatively, memory 2504 may be distributed acrossmultiple computing devices 2500, e.g., in a virtualized environment inwhich instruction processing is carried out on multiple computingdevices 2500. For the purposes of this disclosure, “computer storagemedia,” “computer-storage memory,” “memory,” and “memory devices” aresynonymous terms for memory 2504, and none of these terms includecarrier waves or propagating signaling.

Processor(s) 2506 may include any quantity of processing units that readdata from various entities, such as memory 2504 or I/O components 2512.Specifically, processor(s) 2506 are programmed to executecomputer-executable instructions for implementing aspects of thedisclosure. The instructions may be performed by one or more processors2506 within computing device 2500, or by a processor external tocomputing device 2500. In some examples, processor(s) 2506 areprogrammed to execute instructions such as those illustrated in theflowcharts depicted in the accompanying drawings. Moreover, in someexamples, processor(s) 2506 represent an implementation of analogtechniques to perform the operations described herein. For example, theoperations may be performed by an analog computing device 2500 and/or adigital computing device 2500. Presentation component(s) 2508 presentdata indications to a user or other device. Exemplary presentationcomponents 2508 include a display device, speaker, printing component,vibrating component, etc. One skilled in the art will understand andappreciate that computer data may be presented in a number of ways, suchas visually in a graphical user interface (GUI), audibly throughspeakers, wirelessly between computing devices 2500, across a wiredconnection, or in other ways. I/O ports 2510 allow computing device 2500to be logically coupled to other devices including I/O components 2512,some of which may be built in. Example I/O components 2512 include amicrophone, joystick, game pad, satellite dish, scanner, printer,wireless device, etc.

Computing device 2500 may operate in a networked environment via networkcomponent 2516 using logical connections to one or more remotecomputers. In some examples, network component 2516 includes a networkinterface card and/or computer-executable instructions (e.g., a driver)for operating the network interface card. Communication betweencomputing device 2500 and other devices may occur using any protocol ormechanism over any wired or wireless connection. In some examples,network component 2516 is operable to communicate data over public,private, or hybrid (public and private) using a transfer protocol,between devices wirelessly using short range communication technologies(e.g., near-field communication (NFC), Bluetooth™ brandedcommunications, or the like), or a combination thereof. For example,network component 2516 communicates over a communication link 2520,through a network 2522, with a cloud resource 2524. Various examples ofcommunication link 2520 include a wireless connection, a wiredconnection, and/or a dedicated link, and in some examples, at least aportion is routed through the internet. In some examples, cloud resource2524 performs at least some of the operations described herein forcomputing device 2500.

Although described in connection with an example computing device 2500,examples of the disclosure are capable of implementation with numerousother general-purpose or special-purpose computing system environments,configurations, or devices. Examples of well-known computing systems,environments, and/or configurations that may be suitable for use withaspects of the disclosure include, but are not limited to, smart phones,mobile tablets, mobile computing devices, personal computers, servercomputers, hand-held or laptop devices, multiprocessor systems, gamingconsoles, microprocessor-based systems, set top boxes, programmableconsumer electronics, mobile telephones, mobile computing and/orcommunication devices in wearable or accessory form factors, networkPCs, minicomputers, distributed computing environments that include anyof the above systems or devices, and the like. Such systems or devicesmay accept input from the user in any way, including from input devicessuch as a keyboard or pointing device, via gesture input, proximityinput (such as by hovering), and/or via voice input.

Examples of the disclosure may be described in the general context ofcomputer-executable instructions, such as program modules, executed byone or more computers or other devices in software, firmware, hardware,or a combination thereof. The computer-executable instructions may beorganized into one or more computer-executable components or modules.Generally, program modules include, but are not limited to, routines,programs, objects, components, and data structures that performparticular tasks or implement particular abstract data types. Aspects ofthe disclosure may be implemented with any number and organization ofsuch components or modules. For example, aspects of the disclosure arenot limited to the specific computer-executable instructions or thespecific components or modules illustrated in the figures and describedherein. Other examples of the disclosure may include differentcomputer-executable instructions or components having more or lessfunctionality than illustrated and described herein. In examplesinvolving a general-purpose computer, aspects of the disclosuretransform the general-purpose computer into a special-purpose computingdevice when configured to execute the instructions described herein. Byway of example and not limitation, computer readable media comprisecomputer storage media and communication media. Computer storage mediainclude volatile and nonvolatile, removable and non-removable memoryimplemented in any method or technology for storage of information suchas computer readable instructions, data structures, program modules, orthe like. Computer storage media are tangible and mutually exclusive tocommunication media. Computer storage media are implemented in hardwareand exclude carrier waves and propagated signals. Computer storage mediafor purposes of this disclosure are not signals per se. Exemplarycomputer storage media include hard disks, flash drives, solid-statememory, phase change random-access memory (PRAM), static random-accessmemory (SRAM), dynamic random-access memory (DRAM), other types ofrandom-access memory (RAM), read-only memory (ROM), electricallyerasable programmable read-only memory (EEPROM), flash memory or othermemory technology, compact disk read-only memory (CD-ROM), digitalversatile disks (DVD) or other optical storage, magnetic cassettes,magnetic tape, magnetic disk storage or other magnetic storage devices,or any other non-transmission medium that can be used to storeinformation for access by a computing device. In contrast, communicationmedia typically embody computer readable instructions, data structures,program modules, or the like in a modulated data signal such as acarrier wave or other transport mechanism and include any informationdelivery media.

The order of execution or performance of the operations in examples ofthe disclosure illustrated and described herein is not essential and maybe performed in different sequential manners in various examples. Forexample, it is contemplated that executing or performing a particularoperation before, contemporaneously with, or after another operation iswithin the scope of aspects of the disclosure. When introducing elementsof aspects of the disclosure or the examples thereof, the articles “a,”“an,” “the,” and “said” are intended to mean that there are one or moreof the elements. The terms “comprising,” “including,” and “having” areintended to be inclusive and mean that there may be additional elementsother than the listed elements. The term “exemplary” is intended to mean“an example of.” The phrase “one or more of the following: A, B, and C”means “at least one of A and/or at least one of B and/or at least one ofC.”

Having described aspects of the disclosure in detail, it will beapparent that modifications and variations are possible withoutdeparting from the scope of aspects of the disclosure as defined in theappended claims. As various changes could be made in the aboveconstructions, products, and methods without departing from the scope ofaspects of the disclosure, it is intended that all matter contained inthe above description and shown in the accompanying drawings shall beinterpreted as illustrative and not in a limiting sense.

What is claimed is:
 1. A method of using a first blockchain to generateevidence for proving document integrity, the method executable by aprocessor, the method comprising: generating, for a document, a firstrecord in a first format, the first format comprising: an integrityverification code (IVC) field comprising a first IVC portion; and arecord locator field; wherein the first record comprises: a first IVCvalue in the first IVC portion of the IVC field of the first record; anda first value in the record locator field of the first record; andgenerating, in the first blockchain, a first block comprising the firstrecord, wherein the first value in the record locator field of the firstrecord indicates a blockchain address of a second record, different thanthe first record, wherein the blockchain address of the second recordindicates a location of the second record within the blockchain, whereinthe second record is within a second block of the first blockchain thatis prior to the first block in the first blockchain, wherein the firstvalue in the record locator field of the first record includes a blockidentifier of the second block, and wherein the first value in therecord locator field of the first record does not link blocks of thefirst blockchain; and linking the first block to a prior block in thefirst blockchain using an IVC of the prior block in the first blockchainwithin the first block.
 2. The method of claim 1, further comprising:prior to generating the first block, generating, in the blockchain, thesecond block comprising the second record; and linking the second blockto a subsequent block in the first blockchain using an IVC of the secondblock within the subsequent block in the first blockchain.
 3. The methodof claim 1, wherein the first value in the record locator field of thefirst record further includes a position of the second record within thesecond block.
 4. The method of claim 1, further comprising: generatingthe second record in the first format; wherein the second recordcomprises: a third IVC value in the first IVC portion of the IVC fieldof the second record; and a second value in the record locator field ofthe second record, wherein the second value in the record locator fieldof the second record indicates a location of a third record in the firstblockchain, thereby providing a daisy chain of references to the thirdrecord from the first record.
 5. The method of claim 1, wherein thefirst record further comprises: a third value in the record locatorfield of the first record, wherein the third value in the record locatorfield of the first record indicates a blockchain address of a fourthrecord, different than the first record and different than the secondrecord, wherein the blockchain address of the fourth record indicates alocation of the fourth record within the blockchain, wherein the fourthrecord is within a third block of the first blockchain that is prior tothe first block in the first blockchain, wherein the third value in therecord locator field of the first record includes a block identifier ofthe third block, and wherein the third value in the record locator fieldof the first record does not link blocks of the first blockchain.
 6. Themethod of claim 1, wherein the IVC field further comprises a second IVCportion, wherein the first record further comprises a second IVC valuein the second IVC portion, wherein the second IVC value represents asame document as the first IVC value, and wherein the second IVC valuerepresents an output of a different integrity verification function thanthe first IVC value.
 7. The method of claim 1, wherein the first IVCvalue comprises at least a portion of a Secure Hash Algorithm (SHA)message digest, and wherein the SHA message digest is generated by atleast one function selected from the list consisting of: SHA-1, SHA-224,SHA-256, SHA-384, and SHA-512.
 8. The method of claim 1, wherein thefirst format further comprises a timestamp field, wherein the firstrecord further comprises a timestamp value in the timestamp field. 9.The method of claim 1, wherein the first format further comprises anindex field, wherein the first record further comprises a first indexvalue in the index field of the first record; and wherein the secondrecord further comprises a second index value in the index field of thesecond record.
 10. The method of claim 1, wherein the first formatfurther comprises an index field, wherein the first record furthercomprises a first index value in the index field of the first record;and wherein the second record further comprises a second index value inthe index field of the second record.
 11. The method of claim 10,wherein the second index value appears within the record locator fieldof the first record.
 12. The method of claim 10, wherein first value inthe record locator field of the first record further comprises thesecond index value.
 13. The method of claim 10, wherein index valuesplaced in the index field are incremental counts of records within ablock.
 14. The method of claim 1, wherein the blockchain address of thesecond record indicates a starting bit of the second record within thesecond block.
 15. A method of using a first blockchain to generateevidence for proving document integrity, the method executable by aprocessor, the method comprising: receiving a request to reserve ablockchain address for a first record that has not yet been received,the request indicating a future time period; selecting a reservedblockchain address for a first record, the reserved blockchain addressindicating a first block; returning the reserved blockchain address inresponse to the request; after returning the reserved blockchainaddress, receiving the first record; holding the first record untilgenerating the first block; generating the first block; inserting thefirst record in the first block; and linking the first block to a priorblock in the first blockchain using an IVC of the prior block in thefirst blockchain within the first block.
 16. The method of claim 15,wherein the reserved blockchain address further indicates a positionwithin the first block, and wherein inserting the first record in thefirst block comprises: inserting the first record in the first block atthe indicated position.
 17. The method of claim 16, further comprising:inserting the indicated position into an index field of the firstrecord.
 18. The method of claim 15, further comprising: receiving thereserved blockchain address; inserting an indication of the reservedblockchain address into a document; generating the first record for thedocument containing the indication of the reserved blockchain address,wherein the first record comprises an integrity verification code (IVC)for the document; and transmitting the first record across a computernetwork to a collection point for records for the first blockchain.